On Wed, Sep 16, 2009 at 10:30 PM, Juerg Meier <[email protected]> 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 <[email protected]> - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 21 531941, ext 2070
