Yes, Safari and Chrome only cache credentials that were passed to a request and lead to a sucessfull response if they were entered manually through the login box. Putting credentials into an XHR request, or via an image, css, iframe or script via the "http://user:passw...@domain.com"; trick, which mostly works, is seen as dangerous by these browsers and thus they won't cache those credentials for future requests, leading to a login box.
The problem can be solved either by using a Cookie (that has the same contents as the HTTP Authorization field) and which is created by Javascript on the client side or by simply not using the special XHR authentication login and letting the browser popup the auth dialog. Note that the first approach can be a target of XSS attacks, as the cookie is readable by Javascript and will contain the username and password in readable fashion (only base64 encoded). There is no way to make that more secure in this respect, because any mechanism will either require a user session on the server (for some secret session key) and/or change Jackrabbit to accept any password for a trusted component such as the Sling login handler (if you store some "global" session key that is bound to the whole server and not per user). Thus the problem is quite generic with respect to stateless "RESTful" web applications: potentially unsafe code such as Javascript in the browser should not have access to the credentials that the underlying browser sends and caches on behalf of the user. This is the case for the HTTP Authorization header, but not for cookies. Regards, Alex On Thu, Sep 17, 2009 at 01:52, Mike Moulton <m...@meltmedia.com> wrote: > I'm relatively new to sling development and I find myself experiencing a > problem faced by several other developers as it relates to BASIC auth in > WebKit based browsers. > > From my understanding of the problem described in this thread, WebKit is not > consistently sending the Authorization header with every request. (In my > case, I can't get Safari 4 to sent the header past the first request unless > I check the "Remember Password" box) > > The recommended solutions seem to revolve around rolling your own > AuthenticationHandler, similar to AuthorizationHeaderAuthenticationHandler, > implementing a cookie based approach. > > Is this the recommended long term solution for the larger problem, or is the > ideal situation that sling will handle persistent Authentication across all > major browsers "out of the box", it just hasn't been implemented yet? > > I'm about to write my own AuthenticationHandler to solve this problem, and I > would like to get some direction from those who have traveled down this path > already. If the community feels this should be a core service, I will make > an attempt at writing a more generic solution and provide a patch back to > sling. -- Alexander Klimetschek alexander.klimetsc...@day.com
