Hi Mike, In addition to the explanations by Alex Klimetschek you are of course welcome to "enhance" the current HTTP authentication handler with support for cookies for WebKit based browsers....
Regards Felix Mike Moulton schrieb: > 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. > > Regards, > Mike Moulton > > > Begin forwarded message: > >> From: Magnus Johansson <[email protected]> >> Date: August 14, 2009 11:15:33 AM MST >> To: [email protected] >> Subject: Re: WebKit HTTP Authentication >> Reply-To: [email protected] >> >>> >>> As Felix noted, the cookie fallback mechanism is the only stable way >>> to handle all browsers. >> >> >> Unless, of course, you use the "ugly" modal dialog box. That should >> work for >> all browsers >> as well. This is the way I ended up using (by creating a modifyied the >> http >> auth bundle that >> didn't include the form) >> >> /Magnus > Begin forwarded message: > >> From: Alexander Klimetschek <[email protected]> >> Date: August 14, 2009 11:04:19 AM MST >> To: [email protected] >> Subject: Re: WebKit HTTP Authentication >> Reply-To: [email protected] >> >> On Mon, Aug 10, 2009 at 8:18 AM, Felix Meschberger<[email protected]> >> wrote: >>> The problem with WebKit based browsers (Chrome has the same issue) is >>> that the authentication used for AJAX requests are not kept in the cache >>> for future use. Unlike the Gecko based browsers or even MS IE. >> >> Right, WebKit-based browsers seem to cache credentials and send them >> preemptively with every following request *only* if they were actually >> entered by a user. Any other way of injecting the credentials, eg. >> through an XHR or iframe/image/css/script using the >> http://user:[email protected] mechanism, will only work for that >> request (albeit in most cases not sent preemptively), but the >> credentials won't be cached. >> >> If they are entered by a user, ie. through the "ugly" (because >> unstyleable and modal) browser login form, they will be cached and >> sent preemptively for the same subtree (Chrome I think) or whole >> domain (Safari IIRC). Additional "security" I guess. >> >> As Felix noted, the cookie fallback mechanism is the only stable way >> to handle all browsers. >> >> Regards, >> Alex >> >> -- >> Alexander Klimetschek >> [email protected] > Begin forwarded message: > >> From: Felix Meschberger <[email protected]> >> Date: August 9, 2009 11:18:56 PM MST >> To: [email protected] >> Subject: Re: WebKit HTTP Authentication >> Reply-To: [email protected] >> >> Hi Andreas, >> >> Andreas Kollegger schrieb: >>> "Apache Sling HTTP Header Authentication" doesn't seem to work with >>> Safari (and I presume other WebKit browsers). Could anyone share some >>> insight into what is wrong, or point me to the relevant JIRA issue? I'm >>> not familiar with the details of http-authentication, so tracing through >>> the code only got me far enough to realize something wasn't happening as >>> expected on the browser side. >> >> The problem with WebKit based browsers (Chrome has the same issue) is >> that the authentication used for AJAX requests are not kept in the cache >> for future use. Unlike the Gecko based browsers or even MS IE. >> >> In an internal project we worked around this issue by inspecting the >> client request header and setting a cookie with the credentials instead >> of using the 401 response together with the AJAX request to update the >> browser's credentials cache. >> >> Now when authenticating the request we not only look for the HTTP >> authentication header (as expected after a 401 authentication) but also >> for the cookie. >> >> Regards >> Felix > > :: mike moulton > :: meltmedia > :: [email protected] > >
