Hi, Am 17.09.2010 23:48, schrieb Ian Boston: > > On 18 Sep 2010, at 00:59, Felix Meschberger wrote: > >> Hi all, >> >> I am trying to tackle issues SLING-1400 [1] and SLING-1745 [2]. >> >> The first issue is about WebDAV clients connecting to Sling on root with >> an OPTIONS request and not being happy with a redirect response, obviously. >> >> The second issue is about client side JavaScript application framework >> which may send XHR requests to Sling, mainly POSTs destined for the POST >> Servlet but probably also other stuff. Such framework are also generally >> not very happy getting redirect responses back. >> >> Solutions for both problems would probably have to be implemented in the >> SlingAuthenticator.doLogin method, which is called after an unsuccessful >> login or after a first request noticing that authentication is required. >> >> So here are the options I came up with: >> >> * Send back a 401 response, at least for the OPTIONS request >> to trigger a regular HTTP Basic Authentication >> * Send back a 403 response, to indicate that access is currently >> forbidden (we discussed this option earlier [3]). >> >> My questions: >> >> - Would it be ok to special case the OPTIONS request ? > > IMHO Yes, as AFAIK its only normally seen with webdav. > >> - Shall we generally only send back a generic credentials request >> (may be a redirect or a form directly or whatever) if the >> original request was GET and send back either 401 or 403 for >> all non-GET requests, including HEAD ? > > The credentials request should include something that doesn't need to be > parsed to indicate it is a credentials request. (header or status code).
Hmm, adding an X-Reason header duplicating the value of the (optional) j_reason parameter from the redirect response sounds like an option here. > > Redirect or form is Ok provided the request is not Ajax. If it is, then who > knows what the client will do, in which case status code is really the only > correct way of responding. Can you do a 401/403 and the html, redirect in as > a meta-equiv if required. Not sure, whether I understand. As for the 401 response we can probably not add anything be cause the browser immediately displays the regular browser login box without much ado. For 403 it might be an option, indeed to provide information as to what URL to request to allow the client to login possibly having the client open another window for this action.... > > >> - Is it a good idea to send back 401 generally ? >> - Should we only send back 401 if HTTP Basic authentication is >> at enabled fully or enabled preemptively and send back 403 if >> HTTP Basic authentication is switched off completely ? > > This prompted me to go and look at the spec[1]. > 401 must be have a WWW-Authenticate which will cause the login box to appear > (iirc) even with Ajax requests. > And there is no way to know if the client wants to see a login box. Could be > very confusing for anyone with SSO or Form based auth. That's exactly why I am reluctant to just send back 401... I will post a patch to codereview.appspot for further discussion. Regards Felix > > Sending a bare 401 might be the right thing to do where the user is anon, but > that would be illegal, perhaps the client can work out that they are not > logged in, which makes 403 Ok. > > Ian > > > 1 http://www.freesoft.org/CIE/RFC/2068/209.htm > >> - Am I completely off track ? >> >> WDYT ? >> >> Regards >> Felix >> >> >> >> [1] https://issues.apache.org/jira/browse/SLING-1400 >> [2] https://issues.apache.org/jira/browse/SLING-1745 >> [3] http://markmail.org/message/jwsvk6swnxvvfsyz > >
