[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saml-dev] Question about the base64 encoding in Browser/POST profile
Hi Scott,
The encoding of HTML pages between two parties needs to be specified before
any data is transfered betwen them. The encoding of HTML pages is
determined at the server.
The encoding of HTML pages tells the browser which encoding to use
automatically, it also determines the ecoding that is sent to a server from
the initially returned form. In other words, if the encoding of a form is
in UTF-8, input text returned from a browser is encoded in UTF-8 as well.
There are basically two ways to specify the encoding of an HTML page :
1. Specify the encoding in the HTTP header(Examples in Java/JSP)
<%@ page contentType="text/html; charset=utf-8" %>
or
res.setContentType("text/html; charset=utf-8");
2. Specify the encoding in the HTML page header
<HTML><HEAD><TITLE>Html Ecoding Example</TITLE>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
</HEAD>
...
</HTML>
Input passed from a browser in a POST request is different from that in a
GET request:
· For POST requests, input is passed as part of the request body, and 8-bit
data is allowed.
· For GET requests, input is passed as part of a URL as an embedded query
string where every non-ASCII byte is encoded as %XX where XX is the
hexadecimal representation for the binary value of the byte.
The reason why a Relying Party and Asserting Parting need to agree on the
encoding prior to their interaction is because most JSP and Servlet
containers assume incoming form input is in the ISO-8859-1 encoding. As a
result, when the HttpServletRequest.getParameter() API is called, all
embedded %XX data of the input text is decoded, and the decoded input is
converted from ISO-8859-1 to Unicode and returned as a Java string. This
results in corrupt data.
In order to properly convert the data from UTF-8 to Java's encoding
correctly you will need to do the following in your server code at the
receiving party:
String original = request.getParameter("assertion");
try
{
String real = new String(original.getBytes("8859_1"),"UTF8");
}
catch (UnsupportedEncodingException e)
{
String real = original;
}
or if you have a servlet 2.3 web container you could:
request.setCharacterEncoding("UTF8");
String real = request.getParameter("assertion");
I am interested in helping with the SAML 1.1 spec in any way possible.
I have already written a SAML chapter for OWASP's Web Application Security
Guidebook and have extensive experience with Internationalization (which use
different encodings).
Regards,
Abraham Kang
Security System Architect
Apexon
----- Original Message -----
From: "Scott Cantor" <cantor.2@osu.edu>
To: "'Westbrock, Jon [FRCO/RTC]'" <Jon.Westbrock@EmersonProcess.com>;
<saml-dev@lists.oasis-open.org>
Sent: Monday, March 17, 2003 9:28 AM
Subject: RE: [saml-dev] Question about the base64 encoding in Browser/POST
profile
> >Any insight you can provide would be appreciated.
>
> I think it would be useful for somebody with base64 and character encoding
knowledge to help address this issue in the 1.1 spec
> revision being worked on.
>
> Basically the answer to your question is that it's underspecified, and I
have no idea what the right text should be, but we need
> something better.
>
> -- Scott
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]