Item4929: need to work out howto deal with access denied error in rest

right now I made it return 401, with the assumption that we cna find a way to send an auth header, but the more i contemplate the reality of this, the more I think it'll have to be changed to 403 or 404 (404 would be more secure, as its not confirming or denying the existance of the resource)

TWiki:Main/SvenDowideit - 05 Nov 2007

I think 401 is right. 403 suggests that the request is totally forbidden, so if definitely wrong. 404 is the HTTP equivalent of sticking your fingers in your ears and singing la la la I can't heeeeaaaar you, and really isn't a sensible response to a well-formed request.

We really ought to make it easier for a REST function to return a sensible status code. At the moment you have to generate your own headers (I use modifyHeaderHandler) to return a status

-- TWiki:Main.CrawfordCurrie - 05 Nov 2007

I really don't think this is Urgent. We can code handlers to return status codes, and it's a matter of convention that they obey the HTTP standards. I think it's the subject for individual plugins to "do it properly". I can't see any reason why we should block 4.2.0 because of it (happy to be convinced otherwise)

Dropping to Normal.

CC

the problem is that 401 must send an auth request to the browser - so if we stick with 401, we still have work todo.

-- TWiki:Main.SvenDowideit - 15 Nov 2007

I am not certain, but I think Item5548 http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5548 is a result of this issue not blocking 4.2...

-- TWiki:Main.GavinMcDonald - 25 Apr 2008

I don't think so. I only use the REST handlers from WysiwygPlugin and they never raise access control violations; they have no need to, because all the information is provided to them in the POST request.

-- TWiki:Main.CrawfordCurrie - 25 Apr 2008

It is a year since this was put Being Worked on.

I flip it to New

• KennethLavrsen - 24 Dec 2008

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html states:

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication"

The problem is that the handler that deals with an acces control violation does not add a www-authenticate header.

14.47 WWW-Authenticate

The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.

       WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. User agents are advised to take special care in parsing the WWW- Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.

The specific structure of the challenge depends on the authentication mechanism in use. Note that a 401 should only be issued if the browser is currently unauthenticated in the domain; if someone is already logged in, a 403 should be issued.

IMHO the application should not need to worry about the authorization mechanism in use. It should be able to signal that "the user is unauthorized" and have FSA generate the appropriate header. FSA should rewrite the response, adding WWW-authenticate or changing the status to 403 as appropriate.

See also Item6023 for more discussion of the same problem.

Confirmed.

-- CrawfordCurrie - 04 Jan 2009

I have experienced this issue (or something like it) while porting TWiki:Plugins.ExitPlugin. See Item1359. At the moment the rest script is flagged as requiring authorization by being listed in $Foswiki::cfg{AuthScripts}. Shouldn't the plugin itself (or the rest handler) decide if each verb needs authorization? It might do this by calling a method on $session or throwing Foswiki::AccessControlException.

-- IanBygrave - 26 Mar 2009

This was resolved recently.

-- CrawfordCurrie - 21 Mar 2012