How to: server side authentication with xmlHttpRequest password user (best practices?)

372 views
Skip to first unread message

Rebornspirit

unread,
May 31, 2008, 3:55:24 PM5/31/08
to Google Web Toolkit
GWT 1.5 has this new cool feature of being able to set the user name
and password on the xmlHttpRequest, but how does this impact the
server side authentication, how do I get the user and password back
from that xmlHttpRequest on the server (using Acegi)?

I'm probably missing something stupid about the xmlHttpRequest, the
user / pwd are on the url no? but I just don't get it .. it has been a
long day perhaps that is it....

Or is it better to store the user / password in the request header

Perhaps a last question, I don't want to store the user / pwd manually
on a per request basis (on each rpc method call manually), what is the
best place to extend so this can be done for all my rpc method calls?

Grtz

Mark Renouf

unread,
Jun 1, 2008, 10:09:25 AM6/1/08
to Google Web Toolkit
This is sent using Basic Auth. Usually you'd configure your web server
to verify this and reject the request with a 401 if it was missing or
invalid. To test it within your code, you'll want to check the
"Authorization" header of the request for this information.

The format is base64("<username>:<password>")

You can use apache commons-codec for a convenient base64
implementation: Base64.b64decode(...)

PS: You can could also stuff other values into an arbitrary header:
RequestBuilder.setHeader(header, value)

Rebornspirit

unread,
Jun 1, 2008, 4:43:09 PM6/1/08
to Google Web Toolkit
When I set the user / password I don't see anything being added on the
Authorization request header ... strange, when I put them manually
using setHeader it works fine. Any idea what is going on?
The strange thing is that when I add a header manually, let's say with
the wrong user / password AND I set the user and password manually
than the following is happening (I'm using Acegi basic authentication
filters here)
- basic authentication filter gets called with in the auth header that
wrong user / password
- right after a second call to that authentication filter is happening
BUT this time that same Auth header contains the user / password I set
manually, so the correct ones??? what is happening here? And why isn't
this auth header filled in when I only set user / password and not the
header?

I'm confused :-D

Thomas Broyer

unread,
Jun 1, 2008, 6:30:56 PM6/1/08
to Google Web Toolkit


On Jun 1, 10:43 pm, Rebornspirit <maarten.vold...@gmail.com> wrote:
> When I set the user / password I don't see anything being added on the
> Authorization request header ... strange, when I put them manually
> using setHeader it works fine. Any idea what is going on?
> The strange thing is that when I add a header manually, let's say with
> the wrong user / password AND I set the user and password manually
> than the following is happening (I'm using Acegi basic authentication
> filters here)
> - basic authentication filter gets called with in the auth header that
> wrong user / password
> - right after a second call to that authentication filter is happening
> BUT this time that same Auth header contains the user / password I set
> manually, so the correct ones??? what is happening here? And why isn't
> this auth header filled in when I only set user / password and not the
> header?
>
> I'm confused :-D

The browser first check the server expects credentials (and how:
Basic, Digest, etc.); because you explicitly set the Authorization
header, it is sent as well. Your filter sends a 401, so the browser
knows that the server expects credentials and now knows how to send
them too.

If the browser was sending credentials without this first check, it
would send them with Basic auth scheme (Digest requires a nonce issued
by the server), so the password is sent "in the clear"; this would be
a huge security hole.
Reply all
Reply to author
Forward
0 new messages