You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Mike Moulton <mi...@meltmedia.com> on 2009/09/17 01:52:30 UTC
Re: WebKit HTTP Authentication
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 <kk...@gmail.com>
> Date: August 14, 2009 11:15:33 AM MST
> To: dev@sling.apache.org
> Subject: Re: WebKit HTTP Authentication
> Reply-To: dev@sling.apache.org
>
>>
>> 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 <ak...@day.com>
> Date: August 14, 2009 11:04:19 AM MST
> To: dev@sling.apache.org
> Subject: Re: WebKit HTTP Authentication
> Reply-To: dev@sling.apache.org
>
> On Mon, Aug 10, 2009 at 8:18 AM, Felix
> Meschberger<fm...@gmail.com> 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:password@server.com 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
> alexander.klimetschek@day.com
Begin forwarded message:
> From: Felix Meschberger <fm...@gmail.com>
> Date: August 9, 2009 11:18:56 PM MST
> To: dev@sling.apache.org
> Subject: Re: WebKit HTTP Authentication
> Reply-To: dev@sling.apache.org
>
> 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
:: mike@meltmedia.com
Re: WebKit HTTP Authentication
Posted by Alexander Klimetschek <ak...@day.com>.
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:password@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 <mi...@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.klimetschek@day.com
Re: WebKit HTTP Authentication
Posted by Eric Norman <er...@gmail.com>.
Hi Mike and Andreas,
Sure, I'm more than willing to share. I have extracted the form auth
components and created a new bundle. It's attached to
https://issues.apache.org/jira/browse/SLING-1116
Please give it a try and let me know what you think.
Regards,
-Eric
On Thu, Sep 17, 2009 at 9:16 AM, Mike Moulton <mi...@meltmedia.com> wrote:
> Eric,
>
> It sounds like your solution is the start of the approach I was
> considering. If your willing to share, at minimum, Andreas and myself would
> love to look at your solution.
>
> -- Mike
>
>
>
> On Sep 17, 2009, at 8:44 AM, Andreas Kollegger wrote:
>
> Hi Eric,
>>
>> I've been putting off implementing alternative authentication, suffering
>> along
>> with the default browser auth for now. I'd be interested in using your
>> solution
>> if you're willing to share it.
>>
>> Thanks,
>> Andreas
>>
>>
>> On Sep 17, 2009, at 11:29 AM, Eric Norman wrote:
>>
>> Well, my project doesn't currently have enough load to require more than
>>> one
>>> server node, so I haven't thought much about that yet. If your cluster
>>> can
>>> be configured to use sticky sessions, it would probably work fine without
>>> any further changes. Otherwise your app server would need to be
>>> configured
>>> to perform session replication to avoid the login prompt when you get
>>> routed
>>> to a different server node.
>>>
>>> Does that make sense?
>>>
>>> On Thu, Sep 17, 2009 at 7:45 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>
>>> On Thu, Sep 17, 2009 at 4:00 PM, Eric Norman <er...@gmail.com>
>>>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Does your approach handle clustered scenarios?
>>>>
>>>> --
>>>> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
>>>> Sommerrogata 13-15, N-0255 Oslo, Norway
>>>> + 47 22 00 84 00 / +47 21 531941, ext 2070
>>>>
>>>>
>>
> :: mike moulton
> :: meltmedia
> ::
> :: mike@meltmedia.com
> :: 602.648.6810 | direct
> :: 602.432.2568 | iphone
> :: mmoulton66 | aim
>
>
Re: WebKit HTTP Authentication
Posted by Mike Moulton <mi...@meltmedia.com>.
Eric,
It sounds like your solution is the start of the approach I was
considering. If your willing to share, at minimum, Andreas and myself
would love to look at your solution.
-- Mike
On Sep 17, 2009, at 8:44 AM, Andreas Kollegger wrote:
> Hi Eric,
>
> I've been putting off implementing alternative authentication,
> suffering along
> with the default browser auth for now. I'd be interested in using
> your solution
> if you're willing to share it.
>
> Thanks,
> Andreas
>
>
> On Sep 17, 2009, at 11:29 AM, Eric Norman wrote:
>
>> Well, my project doesn't currently have enough load to require more
>> than one
>> server node, so I haven't thought much about that yet. If your
>> cluster can
>> be configured to use sticky sessions, it would probably work fine
>> without
>> any further changes. Otherwise your app server would need to be
>> configured
>> to perform session replication to avoid the login prompt when you
>> get routed
>> to a different server node.
>>
>> Does that make sense?
>>
>> On Thu, Sep 17, 2009 at 7:45 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>
>>> On Thu, Sep 17, 2009 at 4:00 PM, Eric Norman <eric.d.norman@gmail.com
>>> >
>>> wrote:
>>>> 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.
>>>
>>> Does your approach handle clustered scenarios?
>>>
>>> --
>>> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
>>> Sommerrogata 13-15, N-0255 Oslo, Norway
>>> + 47 22 00 84 00 / +47 21 531941, ext 2070
>>>
>
:: mike moulton
:: meltmedia
::
:: mike@meltmedia.com
:: 602.648.6810 | direct
:: 602.432.2568 | iphone
:: mmoulton66 | aim
Re: WebKit HTTP Authentication
Posted by Andreas Kollegger <ak...@tembopublic.org>.
Hi Eric,
I've been putting off implementing alternative authentication,
suffering along
with the default browser auth for now. I'd be interested in using your
solution
if you're willing to share it.
Thanks,
Andreas
On Sep 17, 2009, at 11:29 AM, Eric Norman wrote:
> Well, my project doesn't currently have enough load to require more
> than one
> server node, so I haven't thought much about that yet. If your
> cluster can
> be configured to use sticky sessions, it would probably work fine
> without
> any further changes. Otherwise your app server would need to be
> configured
> to perform session replication to avoid the login prompt when you
> get routed
> to a different server node.
>
> Does that make sense?
>
> On Thu, Sep 17, 2009 at 7:45 AM, Vidar Ramdal <vi...@idium.no> wrote:
>
>> On Thu, Sep 17, 2009 at 4:00 PM, Eric Norman
>> <er...@gmail.com>
>> wrote:
>>> 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.
>>
>> Does your approach handle clustered scenarios?
>>
>> --
>> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
>> Sommerrogata 13-15, N-0255 Oslo, Norway
>> + 47 22 00 84 00 / +47 21 531941, ext 2070
>>
Re: WebKit HTTP Authentication
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Sep 17, 2009 at 18:15, Mike Moulton <mi...@meltmedia.com> wrote:
> My applications undergo auditing to meet strict security protocols, therefor
> I generally stay away from BASIC auth due to the in-the-clear nature of the
> Authorization header unless the entire session is planned to be delivered
> over SSL. With the exception of Eric's implementation where a crypted
> version is stored on the server and referenced by a session id, how are
> others dealing with these inherent security risk in a production
> environment?
On Thu, Sep 17, 2009 at 17:51, Vidar Ramdal <vi...@idium.no> wrote:
> I realize that authentication must be hard in any truly REST-based system.
Using HTTP basic auth (no cookies) + SSL is probably the way to go for
REST-based systems.
Other than that, you could try all kinds of things to either make user
sessions (at least the secret keys) be distributed around the cluster
fast (good potential for failure) or make the load balancing put users
always on the same server (or set of servers that are easily
synchronized), to keep scalability. And only do that for users that
need to be logged in so that the anonymous GET requests are unaffected
by that and stay fully scalable.
Also, Kerberos could be an answer, but I don't know if it is scalable
or if it is possible to use it across all browsers.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: WebKit HTTP Authentication
Posted by Mike Moulton <mi...@meltmedia.com>.
Thank you everyone for your thorough responses, they are of great help.
In the interest of keeping the conversation going...
My applications undergo auditing to meet strict security protocols,
therefor I generally stay away from BASIC auth due to the in-the-clear
nature of the Authorization header unless the entire session is
planned to be delivered over SSL. With the exception of Eric's
implementation where a crypted version is stored on the server and
referenced by a session id, how are others dealing with these inherent
security risk in a production environment?
-- Mike
Without session affinity
On Sep 17, 2009, at 8:51 AM, Vidar Ramdal wrote:
> On Thu, Sep 17, 2009 at 5:29 PM, Eric Norman
> <er...@gmail.com> wrote:
>> Well, my project doesn't currently have enough load to require more
>> than one
>> server node, so I haven't thought much about that yet. If your
>> cluster can
>> be configured to use sticky sessions, it would probably work fine
>> without
>> any further changes. Otherwise your app server would need to be
>> configured
>> to perform session replication to avoid the login prompt when you
>> get routed
>> to a different server node.
>>
>> Does that make sense?
>
> Yes, thanks. That's what I thought.
> I realize that authentication must be hard in any truly REST-based
> system.
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00 / +47 21 531941, ext 2070
:: mike moulton
:: meltmedia
:: mike@meltmedia.com
Re: WebKit HTTP Authentication
Posted by Vidar Ramdal <vi...@idium.no>.
On Thu, Sep 17, 2009 at 5:29 PM, Eric Norman <er...@gmail.com> wrote:
> Well, my project doesn't currently have enough load to require more than one
> server node, so I haven't thought much about that yet. If your cluster can
> be configured to use sticky sessions, it would probably work fine without
> any further changes. Otherwise your app server would need to be configured
> to perform session replication to avoid the login prompt when you get routed
> to a different server node.
>
> Does that make sense?
Yes, thanks. That's what I thought.
I realize that authentication must be hard in any truly REST-based system.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: WebKit HTTP Authentication
Posted by Eric Norman <er...@gmail.com>.
Well, my project doesn't currently have enough load to require more than one
server node, so I haven't thought much about that yet. If your cluster can
be configured to use sticky sessions, it would probably work fine without
any further changes. Otherwise your app server would need to be configured
to perform session replication to avoid the login prompt when you get routed
to a different server node.
Does that make sense?
On Thu, Sep 17, 2009 at 7:45 AM, Vidar Ramdal <vi...@idium.no> wrote:
> On Thu, Sep 17, 2009 at 4:00 PM, Eric Norman <er...@gmail.com>
> wrote:
> > 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.
>
> Does your approach handle clustered scenarios?
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00 / +47 21 531941, ext 2070
>
Re: WebKit HTTP Authentication
Posted by Vidar Ramdal <vi...@idium.no>.
On Thu, Sep 17, 2009 at 4:00 PM, Eric Norman <er...@gmail.com> wrote:
> 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.
Does your approach handle clustered scenarios?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: WebKit HTTP Authentication
Posted by Eric Norman <er...@gmail.com>.
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 <mi...@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.
>
> Regards,
> Mike Moulton
>
>
> Begin forwarded message:
>
> From: Magnus Johansson <kk...@gmail.com>
>> Date: August 14, 2009 11:15:33 AM MST
>> To: dev@sling.apache.org
>> Subject: Re: WebKit HTTP Authentication
>> Reply-To: dev@sling.apache.org
>>
>>
>>> 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 <ak...@day.com>
>> Date: August 14, 2009 11:04:19 AM MST
>> To: dev@sling.apache.org
>> Subject: Re: WebKit HTTP Authentication
>> Reply-To: dev@sling.apache.org
>>
>> On Mon, Aug 10, 2009 at 8:18 AM, Felix Meschberger<fm...@gmail.com>
>> 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:password@server.com 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
>> alexander.klimetschek@day.com
>>
> Begin forwarded message:
>
> From: Felix Meschberger <fm...@gmail.com>
>> Date: August 9, 2009 11:18:56 PM MST
>> To: dev@sling.apache.org
>> Subject: Re: WebKit HTTP Authentication
>> Reply-To: dev@sling.apache.org
>>
>> 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
> :: mike@meltmedia.com
>
>
Re: WebKit HTTP Authentication
Posted by Felix Meschberger <fm...@gmail.com>.
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 <kk...@gmail.com>
>> Date: August 14, 2009 11:15:33 AM MST
>> To: dev@sling.apache.org
>> Subject: Re: WebKit HTTP Authentication
>> Reply-To: dev@sling.apache.org
>>
>>>
>>> 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 <ak...@day.com>
>> Date: August 14, 2009 11:04:19 AM MST
>> To: dev@sling.apache.org
>> Subject: Re: WebKit HTTP Authentication
>> Reply-To: dev@sling.apache.org
>>
>> On Mon, Aug 10, 2009 at 8:18 AM, Felix Meschberger<fm...@gmail.com>
>> 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:password@server.com 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
>> alexander.klimetschek@day.com
> Begin forwarded message:
>
>> From: Felix Meschberger <fm...@gmail.com>
>> Date: August 9, 2009 11:18:56 PM MST
>> To: dev@sling.apache.org
>> Subject: Re: WebKit HTTP Authentication
>> Reply-To: dev@sling.apache.org
>>
>> 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
> :: mike@meltmedia.com
>
>