Hi Mike, For my own project, I ended up writing my own FormAuthenticationHandler which caches the submitted credentials (crypted) on the server-side as a session attribute. The cached credentials are used when no basic auth info is available on the current request. It is actually not that hard to implement, there were a couple servlets (LoginServlet, LogoutServlet) and an AuthenticationHandler class plus an esp script to render the login page.
I could provide a patch if you are interested. Regards, -Eric Norman On Wed, Sep 16, 2009 at 4:52 PM, Mike Moulton <[email protected]> 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. > > 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] > >
