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 <[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.
