Use object instead of iframe - but it wont work in IE

In the spring of 2007, when I established my blog, I used quite some energy to make the markup valid. One of the issues was to achieve strict validation which demands that I abandon Iframe, see the post Sweetxml: Valid XHTML - the blogger navigation bar. The other day I was browsing the excellent 456bereastreet, and stumbled upon Dump iframes and use object elements instead. This awoke my strides to make the navbar visible in IE, something I had problems achieving then and to conclude quickly I still have, but now I know exactly why. Before twisting my template I looked like this in IE:

The post on 456Bereastreet actually was just a reference to the post Insert HTML page into another HTML page. Rushed through the example and tried it out my self to find that the exactly same classid lay as a comment in my template from an earlier attempt. I wasn't let down so I tried it once more, but there was no change. After doing some surfing i read some of the comments to find the answer right there. IE doesn't allow content from other domains (maybe even hosts) and it looks like not even a P3P compact policy might help, since in IE <object/> is obviously viewed as ActiveX per se. With an exact diagnosis it was now possible to look for ways around, but there are none except from creating a custom security setting i IE:

I would suspect many users to have this setting, and it get even worse. Due to the expectation that the content i ActiveX, it gives this warning:

welcome to my innocent and ad-free blog! If a use goes through all this she'll end up with the navbar actually being visible:

The extra vertical scrollbar can be removed with CSS2, but I wont bother since I'll be reverting to my former template again.

Styling my WSRP portlets - does these CSS classes really give us common look-and-feel?

I do believe that the standard is missing something but I not sure the scale of it (what's missing and what's the problem). Since I have limited web-developer experience and less on the layout part and very little experience with JSR-168 and/or WSRP 1.0 [PDF] I'm doing this solely from dry paper analysis.

Since I first started looking at these portlet standards I've been puzzle by this aspect of portlet interoperability: common look-and-feel. I don't think it's simple to write down look-and-feel, and without common understanding it's harder to implement. In this post I'll focus only on the look/layout element, as in the question: can my portlets just be plugged-in and powered up as an integrated part of a portal or more probable what's missing? To be honest I'll not answer that question (for now) but I will start on 'an answer'.

Searching the for posts and articles on this subject is to say the least disappointing. The reasons can be some of:

1. it's trivial - nope.
2. no one else cares - likely.
3. no one has tried - it's possible that very few have tried.

To get beyond speculating, I'll start with the Web Services for Remote Portlets 1.0 Primer to look for a simple introduction to the subject. In section 5.4 CSS Portlet Classes:

HTML 4.01 states: “Since style sheets are now the preferred way to specify a document's resentation, the presentational attributes of BODY have been deprecated.” Accordingly, WSRP 1.0 has adopted an initial basic set of CSS classes designed to provide a standard set of display options for portlets. For a list with tables of these portlet classes, see Section 10.6 of WSRP 1.0 specification. Use of CSS portlet classes are optional and only appropriate for those markup types supporting CSS.

Looking into the real specification it starts with (my strong):

One of the goals of an aggregated page is a common look-and-feel across the Portlets contained on that page. This not only affects the decorations around the Portlets, but also their content. Using a common CSS style sheet for all Portlets, and defining a set of standard styles, provides this common look-and-feel without requiring the Portlets to generate Consumer-specific markup. Portlets SHOULD use the CSS style definitions from this specification in order to participate in a uniform display of their content by various Consumers. For markup types that support CSS stylesheets, Consumers MUST supply a CSS stylesheet to the End-User’s agent with definitions for the classes defined in section 10.6 of this specification.

Since my focus is on XHTML markup, CSS is relevant but still it's optional.

The next version of WSRP (2.0) is under development so I had a look at the committee homepage and found the Markup SC whose chartered to oversee definition of fragment rules for various markup languages (this is currently being requested of the various groups that standardize the markup languages) and useful CSS classes. Though this sound promising with regard to some more in depth content, it's deceiving since a look at the documents page shows that the latest document is from 2004-03-31. Looking into the document CSS-REV9-forF2F8.doc only reveals that the input to this work was limited. I'm confirmed in a mail by Rex Brooks with the subject Uploaded CSS REV 8 (my strong):

This is the table of CSS classes we have identified, minus the anchor class which we dropped, and it includes the questions we have never answered because we thought we would have a set of rendered samples to aid our choices. Lacking that or any additional input from member companies, I will answer the questions as best I can and put together a draft for the spec section relevant to CSS classes. If you have questions, comments and/or suggestions, please let me know soonest. I plan to send the final version of this with the hypothetical spec language Friday.

Looking furhter at posts to the mailing list i stumled upon one by Noah Guyot on the subject Contextual Selectors, which has one of the concepts that I've considered usefull:

The way we could use this for portlets is a follows. We could wrap the entire portlet markup in a <div class="portlet"> </div> and make all of the portlets classes contextual. That could help prevent stylesheet clashes.

I haven't found the argument that stopped this from ending in the spec. Another good email from Vignette is from an UI engineer but the gem is from a honest Tibco developer (embedded in another email) that points at all the same problems that I myself have thought about. It looks to me like this input didn't change anything and I sure would like to know what answer he was given.

Update (23/11-2007): Later i found an email from Ken Ramirez to wsrp-comment. He was in the process of writing a book - I guess it's J2EE Portals and Portlets: Create Customized Open Source Portals with J2EE, that's unavailable on Amazon. He's not critical to the conceptual model, but does touch on the sparse documentation. Rich Thompson answers him without any problems, though I think some of the argumentation (and question) doesn't go deep enough.

The WSRP 2.0 - Public Review Draft 04 from the latest 15-day hearing has in section 9.5 CSS Style Definitions no changes to the classes from version 1.0 and primarily some additions to the menu classes. In the wiki the WSRP v2 Public Review comments reveals little interest in this subject so I don't expect further changes but hopefully some en lighting examples later on.

UDDI and WS-I Basic Profile - on the subject of encoding

Lately I've been using some time on UDDI and during my post on case-insensitivity on encoding declations on XML documents I came across WS-I Basic Profile that I haven't looked at for some time. In this post i touch on some the surprises on UDDI, WS-I BP and encoding. The most recent BP document (version 1 branch) is Basic Profile Version 1.2, Working Group Approval Draft (2007-10-24)

describes the relation to UDDI in 5. Service Publication and Discovery:

Note that the Web services that constitute UDDI V2 are not fully conformant with the Profile 1.0 because they do not accept messages whose envelopes are encoded in either UTF-8 and UTF-16 as required by the Profile. (They accept UTF-8 only.) That there should be such a discrepancy is hardly surprising given that UDDI V2 was designed and, in many cases, implemented before the Profile was developed. UDDI's designers are aware of UDDI V2's nonconformance and will take it into consideration in their future work.

i don't agree on their evaluation since the XML Specification demands that XML Processors should support both UTF-8 and UTF-16. More important it's still stuck on UDDI V2.0, which is sort of all right since the other standards are frozen as well. But there's a new version on it's way that can read in Basic Profile Version 2.0, Working Group Draft (2007-10-25). The difference between the version 1 and 2 branch is descibed in 1.3 Compatibility with Basic Profile 1.1 and 1.2:

The Basic Profile 2.0 is the first version of the WS-I Basic Profile that changes the version of SOAP in the profile scope from SOAP 1.1 to the W3C SOAP 1.2 Recommendation. As such, clients, servers and the artifacts that comprise a Basic Profile 1.0, 1.1 or 1.2 conformant application are inherently incompatible with an application that is conformant with the Basic Profile 2.0. However, in general, the Basic Profile WG members have tried to preserve in the Basic Profile 2.0 as much consistency with the guidance and constraints of the Basic Profile 1.0, 1.1 and 1.2 as possible. This has been in part facilitated by the fact that the WG tried to remain consistent in the guidance and constraints of the original Basic Profile with the decisions that were being made in the context of the W3C XML Protocols WG as they were concurrently working on the SOAP 1.2 specificatons. For the most part, issues that were resolved in the context of the development of the Basic Profile 1.0, 1.1 and 1.2 were not revisited.

It's still a WSDL 1.1 thing (not that it's a problem to me) and on UDDI it's the same section 5. Service Publication and Discovery with what looks like the identical content.

One simple conclusion is that if you are relying on UDDI V3.0, you've in principle denied yourself the WS-I Conformance badge (UDDI Conformance claim).

Encoding requirements in UDDI V3.0

One interesting question is whether UDDI V3.0 has changed to WS-I conformance on the mentioned issue. The answer is in section 4.2 XML Encoding Requirements:

All messages sent to and received from UDDI nodes MUST be encoded in either UTF-8 or UTF-16, and MUST specify the Hyper Text Transport Protocol (HTTP) Content-Type header with a charset parameter of "utf-8" or "utf-16" respectively and a content type of text/xml. Other encoding name variants, such as UTF8, UTF_8, etc. MAY NOT be used.

First there's no issue anymore and second It's funny to see both upper and lower case used in the same paragraph, and since the values for charset parameters are given in quotes it looks like it's normative? Nope - in the next paragraph:

All parts of the Content-type header are case insensitive and quotations are optional.

With a reference to Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies though I think RFC 3023 is another good place look XML Media Type. The lat little thing is consequent use af lower case for charset and upper case on the encoding declation in the XML declaration, in ex. 4.1.1 Support for SOAPAction.

The Case on encoding - is "utf-8" and "UTF-8" the same?

I am a techiee so some details grow out of proportions for me. One of those details are how to write the encoding in the XML declaration. Since I've written quite some XML-documents if thought about it many times. Should it be "utf-8" or "UTF-8"? does it make any difference? is it because MS platforms don't care about capital letters and the *NIX does? what's the prettiest?.

Actually I have looked into this before but forgot, so now I'm putting it in a post. There's only one natural source to look at - the specification: Extensible Markup Language (XML) 1.0 (Fourth Edition) [HTML] (W3C Recommendation 16 August 2006, edited in place 29 September 2006). Section "4.3 Parsed Entities" contains a description of the XML declaration ("4.3.1 The Text Declaration") with the encoding related part in "4.3.3 Character Encoding in Entities":

Encoding Declaration

[80] EncodingDecl ::= S 'encoding' Eq ('"' EncName '"' | "'" EncName "'" )
[81] EncName ::= [A-Za-z] ([A-Za-z0-9._] | '-')* /* Encoding name contains only Latin characters */

yes, it's in the regular expression for EncName, both upper and lower cases are allowed. It's written in text further down (my bold):

In an encoding declaration, the values "UTF-8", "UTF-16", "ISO-10646-UCS-2", and "ISO-10646-UCS-4" SHOULD be used for the various encodings and transformations of Unicode / ISO/IEC 10646, the values "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-n" (where n is the part number) SHOULD be used for the parts of ISO 8859, and the values "ISO-2022-JP", "Shift_JIS", and "EUC-JP" SHOULD be used for the various encoded forms of JIS X-0208-1997. It is RECOMMENDED that character encodings registered (as charsets) with the Internet Assigned Numbers Authority [IANA-CHARSETS], other than those just listed, be referred to using their registered names; other encodings SHOULD use names starting with an "x-" prefix. XML processors SHOULD match character encoding names in a case-insensitive way and SHOULD either interpret an IANA-registered name as the encoding registered at IANA for that name or treat it as unknown (processors are, of course, not required to support all IANA-registered encodings).

Looking in IANA "Official Names for Character Sets" gives the same story:

The character set names may be up to 40 characters taken from the printable characters of US-ASCII. However, no distinction is made between use of upper and lower case letters.

So that settles it clearly upper or lower case isn't important, so "UTF-8" or "utf-8" should be interpreted the same.

Where to send the reply to an <AuthnRequest>

Some days ago I was running through a web SSO scenario and I confused myself with where what message goes. In this posting I look into where the IdP sendes the Response on an AuthnRequest. In [SAMLProf] under Web Browser SSO Profile, section "4.1.3.5 Identity Provider Issues <Response> to Service Provider":

The location of the assertion consumer service MAY be determined using metadata (as in [SAMLMeta]). The identity provider MUST have some means to establish that this location is in fact controlled by the service provider. A service provider MAY indicate the SAML binding and the specific assertion consumer service to use in its <AuthnRequest> and the identity provider MUST honor them if it can.

Where the reference to [SAMLMeta] is in section "2.4.4 Element <SPSSODescriptor>":

<AssertionConsumerService> [One or More]

One or more elements that describe indexed endpoints that support the profiles of the Authentication Request protocol defined in [SAMLProf]. All service providers support at least one such endpoint, by definition.

with the example on page 25:

<AssertionConsumerService 
   isDefault="true" 
   index="0"
   Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
   Location="https://ServiceProvider.com/SAML/SSO/Artifact"/>
<AssertionConsumerService 
   index="1"
   Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
   Location="https://ServiceProvider.com/SAML/SSO/POST"/>

In SAMLCore

AssertionConsumerServiceIndex [Optional]

Indirectly identifies the location to which the <Response> message should be returned to the requester. It applies only to profiles in which the requester is different from the presenter, such as the Web Browser SSO profile in [SAMLProf]. The identity provider MUST have a trusted means to map the index value in the attribute to a location associated with the requester. [SAMLMeta] provides one possible mechanism. If omitted, then the identity provider MUST return the <Response> message to the default location associated with the requester for the profile of use. If the index specified is invalid, then the identity provider MAY return an error <Response> or it MAY use the default location. This attribute is mutually exclusive with the AssertionConsumerServiceURL and ProtocolBinding attributes.

AssertionConsumerServiceURL [Optional]

Specifies by value the location to which the <Response> message MUST be returned to the requester. The responder MUST ensure by some means that the value specified is in fact associated with the requester. [SAMLMeta] provides one possible mechanism; signing the enclosing <AuthnRequest> message is another. This attribute is mutually exclusive with the AssertionConsumerServiceIndex attribute and is typically accompanied by the ProtocolBinding attribute.

DK-SAML V2.0

In the hearing version of DK-SAML V2.0 it says in section 4.5.3 Location of Service Provider:

In order to send the response, the Service Providers assertion consumer service must first be located. The SAML profile states that meta data MAY be used for this purpose but in the Danish profile this is a MUST.

which means that the use of AssertionConsumerServiceURL is forbidden in DK-SAML V2.0.

e-Authentication

I've searched the documents from e-Authentication and I haven't found anything so they must be satisfied by the flexibility in the SAML V2.0 specification.

The JavaScript security model - "Same origin policy"

I'm aware of what Cross-site scripting (XSS) are and that browsers implement JavaScript as to avoid it, but I've never known exactly what the rules are. I decided it was time to find out so I started searching for the specifications (knowing that there are several of them):

• JavaScript Language Specification, JavaScript 1.1 [PDF] (10/3/96)
• ECMAScript Language Specification - ECMA-262 (3r d Edition - December 1999)
• ECMAScript Edition 4 Wiki

I found nothing. Maybe I used the wrong keywords but it was an dead end. Rather disappointed I started searching the the 'JavaScript security model' and through that I finally found what it was called Same origin policy. I though I might go with the definition on wikipedia like I've done many times. Voilá there waa a definition:

The term "origin" is defined using the domain name, protocol and port. Two pages belong to the same origin if and only if these three values are the same.

But looking at the examples I could see that some of them failed because of Different host. Not clear, so I looked at the Mozilla resource for same-origin:

The same origin policy prevents document or script loaded from one origin from getting or setting properties of a document from a different origin. The policy dates from Netscape Navigator 2.0.

Mozilla considers two pages to have the same origin if the protocol, port (if given), and host are the same for both pages.

Even more simply explained by Mitch Stoltz in a presentation on Security in Mozilla (2002) in the slide Security Policies: Same-Origin with the formula: Hostnames are compared string-wise.

Update -11/8/2007: I'm picky about the words domain name and hostname (fully qualified). To me they are NOT the same - yes, in rare occasions the are interchangeble - but when wikipedia on same origin states: "The term "origin" is defined using the domain name, protocol and port." i disagree like the Mozilla explanation. As a further side note, the Wikipedia article on Hostname has in the section on "Internet hostnames":

On the Internet, a hostname is a domain name assigned to a host computer. This is usually a combination of the host's local name with its parent domain's name. For example, "en.wikipedia.org" consists of a local hostname ("en") and the domain name "wikipedia.org". This kind of hostname is translated into an IP address via the local hosts file, or the Domain Name System (DNS) resolver. It is possible for a single host computer to have several hostnames; but generally the operating system of the host prefers to have one hostname that the host uses for itself.

Any domain name can also be a hostname, as long as the restrictions mentioned below are followed. So, for example, both "en.wikimedia.org" and "wikimedia.org" are hostnames because they both have IP addresses assigned to them. The domain name "pmtpa.wikimedia.org" is not a hostname since it does not have an IP address, but "rr.pmtpa.wikimedia.org" is a hostname. All hostnames are domain names, but not all domain names are hostnames.

I don't agree, but I could be the odd one

Compared to IE6+ cookie policy

Some months ago I looked at how IE6+ had implemented P3P to control cookie policies (Party cookies - first or third-context) and I guess I had expected the JavaScript policy to be close to this, but it turned out very different, with IE6+ being more lax with the concept of minimal domain.

Wrap up

Update (11/8/2007): The most important thing is that I found out what policy is. There's is a way to ajust to i by setting document.domain in both documents to the same parent domain. So there's an easy trick for hosts on the same parent domain but still no cross domain. My current best guess is to use the CNAME trick again like with cookies, that is you create a CNAME record for someNewHost.on.my.domain.tld to reference the hostname of the cross site. This should work since the comparison is done on the immediate name. It's faily easy if you like adding CNAME records to other sites (domains), and the other site can be called with that hostname and lastly insert the correct value to document.domain. There are even more advanced ways like doing the ajustment by communicating between two iframes by fragment identifiers (and other one).

I am surprised that the description of same-origin policy is not part of the specifications and is left for those that implement it in browsers, but on the other hand it fits nicely with my misconception on the world of JavaScript.

After I wrote this post I found and brilliant article on the subject of same origin a the related security hacks called Same-Origin Policy Part 1: Why we’re stuck with things like XSS and XSRF/CSRF.

Hearing of Danish OIO UDDI Profile Version 1.1 - is the UDDI flower about to bloom?

I remember reading about how UDDI was about to change the way business is run in my first .NET book on C# (version 1.0 of course). The story went something like this: a tired developer that sat in his hotel room and wanted to find a place to eat of his preferences. He would pick up his devlopment tool, search the local UDDI (with the correct paramters - that's tModels) after that he would simply order the table online with web services. Though this is an amazing scenario, it was terrible naive and as such almost dumb. I'll not deny that something similar can be done today or in the near future, but not in a general scope and for certain not with UDDI at it's core. UDDI do have other uses and I guess in the intranet senario it does have penetration, wheres the extranet has mainly seen the big players shutting down the DBR. There is some description of how UDDI has evolved and possible use cases in the Oasis paper UDDI Executive Overview: Enabling Service-Oriented Architecture [PDF](October 2004).

As I've put into the title of this post, with a bit of drama, taken that UDDI is up for it the extranet scenario might become real in a foreseeable future. The good folks of CSI in DNITA has annonced the hearing of the Danish OIO UDDI Profile Version 1.1 (In [PDF] or [DOC]). I'll gladly admit that I haven't figured it all out yet, and I'm curious about what happened to version 1.0, that I've never seen, but the closest was Address resolving service, version 0.8 that was published about 1½ year ago.

To get a 10.000 ft overview over where this fits in a larger picture, you can read the timeline in Visioner og milepæle for serviceorienteret infrastruktur [PDF](Danish only, the title is "Visions and milestones for a service-orienteret infrastructure"). Another great source is the Architecture document that's mentioned in the short reference section which you'll probably need to consult. For my own convenience I've add them here with links:

• [OIOSI-ARCH]: The Architecture of the Danish OIO Service Oriented Infrastructure - Draft version 0.8 [PDF] (In English). A very good introduction to what they are trying to achieve.
• [UDDI-3.0]: UDDI Version 3.0.2, UDDI Spec Technical Committee Draft, Dated 20041019 [HTML]. They just reference version 3 from 2002, but I guess the difference is minimal and just a typo.
• [UDDI-WSDL]: Technical Note: Using WSDL in a UDDI Registry, Version 2.0.2 [HTML].
• [RASP]: OIO Reliable Asynchronous Secure Profile 1.0 [PDF] (English). Once again I'm a little confised about the versioning, since in the document it says version 1.1, but I can only find the hearing version of 1.0

And they forgot a reference for:

• OWSA model T version 1.0 [PDF] - OIO Web Service Arkitektur model Transportbaseret sikkerhed (danish only)

The document contains some examples of using the UDDI Inquiry API, that I've fleshed out to XML-documents:

• find_service.xml
• serviceList.xml
• get_serviceDetails.xml
• serviceDetail.xml
• get_tModelDetail.xml
• tModelDetail.xml

Why does Firefox not show namespace declarations when rendering raw XML?

As long as I have been using Mozilla/Firefox I've been surprised that it didn't present raw XML correct. Firefox to me is the compliant, do-it-right browser and then somehow a core functionality as rendering XML isn't show correct (that's to me). Not that it really makes a difference IE does show it to my likening. I've searched for an answer a couple of times but newer really found an answer, making me just even more estranged. In prior searches I've found a default XSLT stylesheet mentioned and that sounded a least to me as a possible hack, that I could modify that and have it my way (since I guessed it was by some principle that it wasn't implemented already. I've never found any examples of such a hack, so I guess it can't be done. Today i did the search again, this time because I had missed and important difference between two XML documents, one being from UDDI version 2 and the other from version 3 - a difference that's hard to find without the namespace declaration. The example is:

This time I had the luck to find the real reason, which can be read in two bug reports:

• Bug 175946 - Show namespace declarations, doctype, xml declaration and CDATA section markers in XML prettyprinting (xmlns nodes missing)
• Bug 94270 – Implement namespace nodes and namespace axis

My own conclusion is that it looks like I'll have to give up hope for it. The bugs are old, I'm not even sure I understand them correctly and for certain - I can't and wouldn't dare trying to do something about it. I guess this is one of those situations where Open Source is even more frustrating than closed source, since in principle I could just do it myself (and make world a little better place to live) but I simply can't - I can just watch my unskilled hands and weep.