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
On Wed, Sep 16, 2009 at 10:30 PM, Juerg Meier 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/
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 or
something of the sort. you can have that render spool a blank image or
login button.
Regards,
Jonathan 'J5' Coo
On Wed, Sep 16, 2009 at 22:36, Vidar Ramdal 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
> (an
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 th
On 17 Sep 2009, at 07:58, Alexander Klimetschek wrote:
On Wed, Sep 16, 2009 at 22:36, Vidar Ramdal 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 bro
On Thu, Sep 17, 2009 at 1:02 AM, Ian Boston 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, a
On Thu, Sep 17, 2009 at 18:37, Bertrand Delacretaz
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...
> On Thu, Sep 17, 2009 at 18:37, Bertrand Delacretaz
> 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, Alex
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 or
> something of the sort. you can have that rende
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
On Thu, Sep 17, 2009 at 20:47, Vidar Ramdal 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
On Fri, Sep 18, 2009 at 12:58 PM, Alexander Klimetschek
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
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 en
> > ...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
On Fri, Sep 18, 2009 at 12:58 PM, Alexander Klimetschek
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 sha
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 re
17 matches
Mail list logo
