OpenSAML user discussion

[Chad La Joie <>]

This is the problem I suggested it might be.

Java has some annoying differences in encoding defaults.  Strings, for
example, are sorta-UTF-16, streams are equivalent to UTF-8 encoding.
So, when your writing stuff out to a stream directly you have to change
the encoding on either the string or the stream (if it happens to
support that function).

As Laurent noted, the XMLHelper.writeNote is the preferred way to write
stuff out to a stream as it does character encoding conversion.

Paul Hethmon wrote:
> Ok. I've been digging into this all week and have it narrowed down to
> the XML declaration. In my code, I'm using XMLHelper.nodeToString() to
> convert my AuthnRequest to XML before base64 encoding and putting it
> into my form. Essentially what the HTTPPostEncoder does. This results in
> an XML declaration of:
> 
>   <?xml version="1.0" encoding="UTF-16"?>
> 
> Seems reasonable and it gets sent and base64 decoded successfully. At
> this point though, is when the error is thrown when I try to decode it
> using the HTTPPostDecoder. So for fun, I went into my XML on the sending
> side and removed the encoding param. Now, xerces will successfully parse
> it and I end up with a valid AuthnRequest object on the receiving side.
> 
> It seems that xerces is looking for UTF-16, but not finding valid UTF-16
> and so throws the "Content not allowed in prolog" error.
> 
> So I'm still digging here. This is an area that I'm fuzzy in, dealing
> with this level of XML and specifications. So I'm hoping perhaps this
> rings a bell for someone who can provide me with a clue.
> 
> I'm actually using a copy of Xerces I built from the Apache svn
> repository yesterday. That may be good or bad, not sure.
> 
> thanks,
> 
> Paul
> 
> 
> 
> -----Original Message-----
> From: Paul Hethmon 
> [mailto:]
>  
> Sent: Wednesday, April 25, 2007 1:28 PM
> To: 
> 
> Subject: RE: SAXParseException?
> 
> I don't think I'm doing that. In this case, I'm building the
> AuthnRequest object in code, then marshalling it to the XML and encoding
> for the HTTP POST. So I see encoding="UTF-16" on the sending side. On
> the receiving side, I see the same encoding.
> 
> I guess I'll go down the path of compiling xerces to see if I can pull
> out some additional information on what it thinks it sees.
> 
> Paul
> 
> 
> -----Original Message-----
> From: Chad La Joie 
> [mailto:]
>  
> Sent: Wednesday, April 25, 2007 12:47 PM
> To: 
> 
> Subject: Re: SAXParseException?
> 
> Paul, I have seen this error before when I mistakenly encoded the actual
> file I was pulling my SAML from in one manner and then had a different
> encoding specified in the XML prolog.  I think for me I did something
> like encode with UTF-8 and then mistakenly put US-ASCII as the encoding.
>  So, when I looked at the file and the hex it all looked fine but the
> parser was thinking it was something totally different.
> 
> Paul Hethmon wrote:
>> Ok, so I had this working a few weeks ago and can't figure out what
> has
>> changed. I've got a snapshot of the opensaml2 libraries as of about
>> March 23rd that builds (mostly, at least I didn't change much). I'm
>> creating an AuthnRequest in one application and passing it to my Idp.
>> When the Idp goes to decode the incoming HTTP form post, it is
> throwing
>> the exception:
>>
>>  
>>
>>  org.xml.sax.SAXParseException: Content is not allowed in prolog.
>>
>>  
>>
>> So I went back to opensaml2 code and added another logging statement
> to
>> actually print out the base64 decoded value from SAMLRequest. I don't
>> see anything wrong with it, looking at the plain text or flipping the
>> view to hex to make sure there are no "unprintable" characters. From
> my
>> code, I'm calling HTTPPostDecoder.decode().
>>
>>  
>>
>> So the code snippet looks like:
>>
>>  
>>
>> HTTPPostDecoder decode = new HTTPPostDecoder();
>>
>> decode.setParserPool( new ParserPool() );
>>
>> decode.setRequest( request );
>>
>> decode.decode();
>>
>>  
>>
>> Any thoughts on where to look next?
>>
>>  
>>
>> thanks,
>>
>>  
>>
>> Paul
>>
>>  
>>
>> Paul Hethmon
>>
>> 
>>
>> www.clareitysecurity.com
>>
>> cell: 865.250.3517
>>
>> work: 865.769.0456
>>
>>  
>>
> 

-- 
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124