You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Juerg Meier <jc...@proxymit.net> on 2009/09/16 22:30:51 UTC
authorization headers
Hi all,
I observed a strange behavior with the authorization header.
I provide a sling:authRequestLogin parameter on some protected resource, e.g.
/a/b.html?sling:authRequestLogin
If I provide a link to, let's say, /a/b/c.html, than this works nicely, i.e.
the HTTP authorization header is present on that resource.
However calling, let's say, /a/c.html, the authorization header disappears.
And worse, if i link from there back to /a/b/c.html, the credentials (that
is, the Auth header) remains lost.
This does not make sense to me, as the security realm is "Sling
(Development)":
WWW-Authenticate Basic realm="Sling (Development)"
So, imho, an authorization header should be applicable for any repository
node/resource. But it looks like it's applicable only to the node where the
authentication took place and its children.
Can somebody shed light?
Thanks,
Juerg
Re: authorization headers
Posted by Mike Moulton <mi...@meltmedia.com>.
Juerg,
I can confirm your findings with Safari as discussed in the WebKit
HTTP Authentication thread.
At this point, using the trunk of sling, I am unable to use any WebKit
browser with sling where a principal other than anonymous is required.
-- Mike
On Sep 17, 2009, at 3:27 PM, Juerg Meier wrote:
> On Wednesday 16 September 2009 22:55:27 Jonathan Cook wrote:
>> One trick with this is to call a resource-type URI from /a with the
>> authentication requested and that will authenticate the user good to
>> /a/b/c and /a/d , from /a/b/c
>>
>> so just <img src="/a.png?sling:authRequestLogin" alt="auth shim" />
>> or
>> something of the sort. you can have that render spool a blank
>> image or
>> login button.
>>
>> Regards,
>> Jonathan 'J5' Cook
>>
>
> First, thanks for the huge quantity of light to all repliers!
> And sorry that I missed to mention the browsers. I tested with FF
> 3.0.7
> (Linux) and 3.5.3 (win), with IE6 (well, it's still the VW beetle
> among
> browsers...) and Safari 4.0.3 (win). All had (re-)acted the same way.
>
> Jonathan, I implemented your "trick", that is, I authenticated
> hiddenly on /a.
> And this really works fine with FF und IE, but not with Safari! That
> might be
> interesting for the guys discussing in the "WebKit HTTP
> Authentication"
> thread. With Safari, I still get "anonymous" as remoteUser when
> visiting /a/c.html.
>
> So, looks like to support safari and it-s WebKit fellows it'll take
> a form
> based approach. As to read in one of the discussion entries, that
> would
> require an HTTP session, thus not precisely the concept we preferin
> the REST
> world...
>
> -- Juerg
:: mike moulton
:: meltmedia
::
:: mike@meltmedia.com
:: 602.648.6810 | direct
:: 602.432.2568 | iphone
:: mmoulton66 | aim
Re: authorization headers
Posted by Juerg Meier <jc...@proxymit.net>.
On Wednesday 16 September 2009 22:55:27 Jonathan Cook wrote:
> One trick with this is to call a resource-type URI from /a with the
> authentication requested and that will authenticate the user good to
> /a/b/c and /a/d , from /a/b/c
>
> so just <img src="/a.png?sling:authRequestLogin" alt="auth shim" /> or
> something of the sort. you can have that render spool a blank image or
> login button.
>
> Regards,
> Jonathan 'J5' Cook
>
First, thanks for the huge quantity of light to all repliers!
And sorry that I missed to mention the browsers. I tested with FF 3.0.7
(Linux) and 3.5.3 (win), with IE6 (well, it's still the VW beetle among
browsers...) and Safari 4.0.3 (win). All had (re-)acted the same way.
Jonathan, I implemented your "trick", that is, I authenticated hiddenly on /a.
And this really works fine with FF und IE, but not with Safari! That might be
interesting for the guys discussing in the "WebKit HTTP Authentication"
thread. With Safari, I still get "anonymous" as remoteUser when
visiting /a/c.html.
So, looks like to support safari and it-s WebKit fellows it'll take a form
based approach. As to read in one of the discussion entries, that would
require an HTTP session, thus not precisely the concept we preferin the REST
world...
-- Juerg
Re: authorization headers
Posted by Jonathan Cook <jo...@gmail.com>.
One trick with this is to call a resource-type URI from /a with the
authentication requested and that will authenticate the user good to
/a/b/c and /a/d , from /a/b/c
so just <img src="/a.png?sling:authRequestLogin" alt="auth shim" /> or
something of the sort. you can have that render spool a blank image or
login button.
Regards,
Jonathan 'J5' Cook
Vidar Ramdal wrote:
> On Wed, Sep 16, 2009 at 10:30 PM, Juerg Meier <jc...@proxymit.net> wrote:
>
>> Hi all,
>>
>> I observed a strange behavior with the authorization header.
>>
>> I provide a sling:authRequestLogin parameter on some protected resource, e.g.
>>
>> /a/b.html?sling:authRequestLogin
>>
>> If I provide a link to, let's say, /a/b/c.html, than this works nicely, i.e.
>> the HTTP authorization header is present on that resource.
>>
>> However calling, let's say, /a/c.html, the authorization header disappears.
>> And worse, if i link from there back to /a/b/c.html, the credentials (that
>> is, the Auth header) remains lost.
>>
>> This does not make sense to me, as the security realm is "Sling
>> (Development)":
>>
>> WWW-Authenticate Basic realm="Sling (Development)"
>>
>> So, imho, an authorization header should be applicable for any repository
>> node/resource. But it looks like it's applicable only to the node where the
>> authentication took place and its children.
>>
>> Can somebody shed light?
>>
>
> I think this is due to the way the browser handles HTTP
> authentication. If I remember correctly:
>
> When you request /a/b.html?sling:authRequestLogin, and gets a HTTP
> login dialog, the browser stores the credentials for the path /a/b
> (and all paths underneath it).
> Thus, the browser will not send the credentials when you request
> /a/c.html, since that path is not underneath /a/b.
>
> However, if you request /a?sling:authRequestLogin first, auth headers
> will be sent on subsequent requests to /a/b and /a/c.
>
>
Re: authorization headers
Posted by Peter Chiochetti <pc...@myzel.net>.
Am 2009-09-16 23:58, schrieb Alexander Klimetschek:
> Right, and this can be different from browser to browser. In my
> experience, Firefox and IE are not that strict and will apply cached
> credentials for the same realm on the entire domain (eg. my.app.com/),
> so you shouldn't see this problem with them (but I am not sure, maybe
> it is only the case in certain versions of them).
>
> Safari and Chrome (ie. Webkit-based ones, although HTTP and Credential
> handling is not part of the core Webkit code) are more strict and will
> definitely apply them for a given resource and its "tree" below. They
> will also only cache credentials that were entered manually, ie. any
> XHR trick to pass in the credentials while avoiding the (ugly) browser
> login dialog will fail there.
IE8 seems to go to latter camp. It will not load a resource from
"/a/b.js" if it previously logged into "b/c.html".
Its a little confusing when sling returns a "200 OK" message with a body
indicating error to a human instead of a 401, 403 or 404 when anonymous
access is denied globally, because that creates a parser error in my
client side script.
--
peter
Re: authorization headers
Posted by Peter Chiochetti <pc...@myzel.net>.
Am 2009-09-18 12:58, schrieb Alexander Klimetschek:
>
> Currently Sling's auth handler will assume that a plain request with
> no credentials is a "new" user that is not yet logged in and will
> redirect him to the login page. That's why there is the special
> sling:authRequestLogin parameter that will enforce the normal behavior
> that the first login request runs through all the steps: send w/o
> credentials, 401, send w/ credentials, 200 => credentials cached
> (depending on browser).
I disabled anonymous access in the felix console. right now I cannot
even find the place again, looks to me like it disappeared, a checkbox I
believe in "embedded jcr repository" it was.
A plain request without credentials now here receives a page with this
content:
> HTTP ERROR 200
>
> Problem accessing /index.html. Reason:
>
> OK
> Powered by Jetty://
Thats a bit of a nuisance, because in my opinion it breaks REST
expectations. What am I doing wrong?
--
peter
RE: authorization headers
Posted by Mike Müller <mi...@mysign.ch>.
> > ...I have created a small browser test suite (with some
> perl cgi to be
> > run in a plain Apache httpd) for that back then when I was
> > experimenting. If you are interested, I could make it publicly
> > available....
>
> That would be cool - it seems like there's much undocumented knowledge
> about all this, if we could expose it somewhere it would be helpful.
>
> -Bertrand
+1
Is there a way to combine the REST-fully basic authentication with the
form based approach to be able to design the Login page?
How does this CRX/CQ? Is it session based there or also via basic
authentication?
If there's a way to combine, basic auth with a Login page, that
should be the standard way which comes bundled with Sling.
WDYT?
best regards
mike
Re: authorization headers
Posted by Bertrand Delacretaz <bd...@gmail.com>.
On Fri, Sep 18, 2009 at 12:58 PM, Alexander Klimetschek
<ak...@day.com> wrote:
> ...I have created a small browser test suite (with some perl cgi to be
> run in a plain Apache httpd) for that back then when I was
> experimenting. If you are interested, I could make it publicly
> available....
That would be cool - it seems like there's much undocumented knowledge
about all this, if we could expose it somewhere it would be helpful.
-Bertrand
Re: authorization headers
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Sep 18, 2009 at 12:32, Vidar Ramdal <vi...@idium.no> wrote:
> On Fri, Sep 18, 2009 at 12:58 PM, Alexander Klimetschek
> <ak...@day.com> wrote:
>> [...]
>> I have created a small browser test suite (with some perl cgi to be
>> run in a plain Apache httpd) for that back then when I was
>> experimenting. If you are interested, I could make it publicly
>> available.
>
> Thank you for sharing your insight.
> Such a testsuite would be great to see.
Months later.... I just noted that I have some webspace on
people.apache.org available for such things, so finally, here it is:
http://people.apache.org/~alexkli/xhr-login.html
You have to install it in a local Apache webserver, as I couldn't get
it to run on people.apache.org. The config there is too restricted for
the rewrite and CGI options (passing Authorization headers through)
that this perl-based suite requires.
Have fun,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: authorization headers
Posted by Vidar Ramdal <vi...@idium.no>.
On Fri, Sep 18, 2009 at 12:58 PM, Alexander Klimetschek
<ak...@day.com> wrote:
> [...]
> I have created a small browser test suite (with some perl cgi to be
> run in a plain Apache httpd) for that back then when I was
> experimenting. If you are interested, I could make it publicly
> available.
Thank you for sharing your insight.
Such a testsuite would be great to see.
--
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: authorization headers
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Sep 17, 2009 at 20:47, Vidar Ramdal <vi...@idium.no> wrote:
> Are you sure about the XHR request part?
>
> That's not my experience with Safari, it won't send the Authentication
> header on subsequent requests if not explicitly asked for it (by the
> server sending WWW-Authenticate) on every request. I'll see if I can
> come up with some steps to reproduce it.
It works with XHR if you don't pass the credentials in the XHR open
call via Javascript but simply let the browser login dialog come up
and enter the credentials manually. After that, Safari 3/4 will cache
them and send them pre-emptively. From that and other behavior I
deducted the "only cache user-entered credentials" principle in
Safari.
For Chrome (I think I tested the first version) it's even more
complicated as he never does preemptive authentication at all (not
sure if they added that in recent versions). So the server must be
able to send the 401 + WWW-Authenticate header *every* time (= doubles
the amount of requests), which is why (popular) browsers quickly
switched to preemptive authentication to improve performance. A "pure"
browser such as Links or Lynx will also never to preemptive
authentication, but I think one can neglect that issue ;-)
Currently Sling's auth handler will assume that a plain request with
no credentials is a "new" user that is not yet logged in and will
redirect him to the login page. That's why there is the special
sling:authRequestLogin parameter that will enforce the normal behavior
that the first login request runs through all the steps: send w/o
credentials, 401, send w/ credentials, 200 => credentials cached
(depending on browser).
Hence with Chrome you not only have to accept the browser-login-dialog
fact, but also make sure the server-side authentication handler
handles 401 answers for all requests. But since you no longer need the
special login page, you would remove that redirect anyway.
I have created a small browser test suite (with some perl cgi to be
run in a plain Apache httpd) for that back then when I was
experimenting. If you are interested, I could make it publicly
available.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: authorization headers
Posted by Vidar Ramdal <vi...@idium.no>.
> On Thu, Sep 17, 2009 at 18:37, Bertrand Delacretaz
> <bd...@gmail.com> wrote:
>> So does that mean that forcing authentication to happen on / using the
>> "ugly" built-in browser credentials dialog works on all current
>> browsers? For user-initiated as well as XHR requests?
On Thu, Sep 17, 2009 at 7:00 PM, Alexander Klimetschek <ak...@day.com> wrote:
> Yes. That would be plain HTTP basic auth... if that does not work it
> can be considered a real browser bug.
Are you sure about the XHR request part?
That's not my experience with Safari, it won't send the Authentication
header on subsequent requests if not explicitly asked for it (by the
server sending WWW-Authenticate) on every request. I'll see if I can
come up with some steps to reproduce it.
--
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: authorization headers
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Sep 17, 2009 at 18:37, Bertrand Delacretaz
<bd...@gmail.com> wrote:
> So does that mean that forcing authentication to happen on / using the
> "ugly" built-in browser credentials dialog works on all current
> browsers? For user-initiated as well as XHR requests?
Yes. That would be plain HTTP basic auth... if that does not work it
can be considered a real browser bug.
> If yes, I'd suggest documenting this as a simple way of managing
> authentication for Sling, without requiring any extensions.
Good idea.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: authorization headers
Posted by Bertrand Delacretaz <bd...@gmail.com>.
On Thu, Sep 17, 2009 at 1:02 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> On 17 Sep 2009, at 07:58, Alexander Klimetschek wrote:
>> ...Firefox and IE are not that strict and will apply cached
>> credentials for the same realm on the entire domain (eg. my.app.com/),...
>> ...Safari and Chrome (ie. Webkit-based ones, although HTTP and Credential
>> handling is not part of the core Webkit code) are more strict and will
>> definitely apply them for a given resource and its "tree" below....
> ...In some browsers Ajax calls dont behave in the same way as the main browser.
> I think some of my co-workers have seen this with IE8, so its probably
> safest to ensure that login happens at /...
So does that mean that forcing authentication to happen on / using the
"ugly" built-in browser credentials dialog works on all current
browsers? For user-initiated as well as XHR requests?
If yes, I'd suggest documenting this as a simple way of managing
authentication for Sling, without requiring any extensions.
-Bertrand
Re: authorization headers
Posted by Ian Boston <ie...@tfd.co.uk>.
On 17 Sep 2009, at 07:58, Alexander Klimetschek wrote:
> On Wed, Sep 16, 2009 at 22:36, Vidar Ramdal <vi...@idium.no> wrote:
>> I think this is due to the way the browser handles HTTP
>> authentication. If I remember correctly:
>>
>> When you request /a/b.html?sling:authRequestLogin, and gets a HTTP
>> login dialog, the browser stores the credentials for the path /a/b
>> (and all paths underneath it).
>> Thus, the browser will not send the credentials when you request
>> /a/c.html, since that path is not underneath /a/b.
>>
>> However, if you request /a?sling:authRequestLogin first, auth headers
>> will be sent on subsequent requests to /a/b and /a/c.
>
> Right, and this can be different from browser to browser. In my
> experience, Firefox and IE are not that strict and will apply cached
> credentials for the same realm on the entire domain (eg. my.app.com/),
> so you shouldn't see this problem with them (but I am not sure, maybe
> it is only the case in certain versions of them).
>
> Safari and Chrome (ie. Webkit-based ones, although HTTP and Credential
> handling is not part of the core Webkit code) are more strict and will
> definitely apply them for a given resource and its "tree" below. They
> will also only cache credentials that were entered manually, ie. any
> XHR trick to pass in the credentials while avoiding the (ugly) browser
> login dialog will fail there.
There is a further complication in this,
In some browsers Ajax calls dont behave in the same way as the main
browser. I think some of my co-workers have seen this with IE8, so its
probably safest to ensure that login happens at /
Ian
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: authorization headers
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Sep 16, 2009 at 22:36, Vidar Ramdal <vi...@idium.no> wrote:
> I think this is due to the way the browser handles HTTP
> authentication. If I remember correctly:
>
> When you request /a/b.html?sling:authRequestLogin, and gets a HTTP
> login dialog, the browser stores the credentials for the path /a/b
> (and all paths underneath it).
> Thus, the browser will not send the credentials when you request
> /a/c.html, since that path is not underneath /a/b.
>
> However, if you request /a?sling:authRequestLogin first, auth headers
> will be sent on subsequent requests to /a/b and /a/c.
Right, and this can be different from browser to browser. In my
experience, Firefox and IE are not that strict and will apply cached
credentials for the same realm on the entire domain (eg. my.app.com/),
so you shouldn't see this problem with them (but I am not sure, maybe
it is only the case in certain versions of them).
Safari and Chrome (ie. Webkit-based ones, although HTTP and Credential
handling is not part of the core Webkit code) are more strict and will
definitely apply them for a given resource and its "tree" below. They
will also only cache credentials that were entered manually, ie. any
XHR trick to pass in the credentials while avoiding the (ugly) browser
login dialog will fail there.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: authorization headers
Posted by Vidar Ramdal <vi...@idium.no>.
On Wed, Sep 16, 2009 at 10:30 PM, Juerg Meier <jc...@proxymit.net> wrote:
> Hi all,
>
> I observed a strange behavior with the authorization header.
>
> I provide a sling:authRequestLogin parameter on some protected resource, e.g.
>
> /a/b.html?sling:authRequestLogin
>
> If I provide a link to, let's say, /a/b/c.html, than this works nicely, i.e.
> the HTTP authorization header is present on that resource.
>
> However calling, let's say, /a/c.html, the authorization header disappears.
> And worse, if i link from there back to /a/b/c.html, the credentials (that
> is, the Auth header) remains lost.
>
> This does not make sense to me, as the security realm is "Sling
> (Development)":
>
> WWW-Authenticate Basic realm="Sling (Development)"
>
> So, imho, an authorization header should be applicable for any repository
> node/resource. But it looks like it's applicable only to the node where the
> authentication took place and its children.
>
> Can somebody shed light?
I think this is due to the way the browser handles HTTP
authentication. If I remember correctly:
When you request /a/b.html?sling:authRequestLogin, and gets a HTTP
login dialog, the browser stores the credentials for the path /a/b
(and all paths underneath it).
Thus, the browser will not send the credentials when you request
/a/c.html, since that path is not underneath /a/b.
However, if you request /a?sling:authRequestLogin first, auth headers
will be sent on subsequent requests to /a/b and /a/c.
--
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