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]
