Redirect with 403 to Security/login

[Ingo Schommer]

I've been writing a FunctionalTest class which checks
the page rendering at different permission levels through
Director::test() (see http://open.silverstripe.com/changeset/66681)

Whenever viewing an existing page is not allowed because
of missing group memberships or login status,
you get redirected to /Security/login with a 302 HTTP Status.
This doesnt provide me with enough info to test the behaviour
(the 302 might be generated by a default redirect or a RedirectorPage).

I've committed a change which redirects all calls to
Security::permissionFailure()
with a 403 instead: http://open.silverstripe.com/changeset/66670

Now, according to the HTTP 1.0 protocol this poses two issues:

1. 403 should just be used if no authorization can be used to access
this resource.
You should use a 401 with WWW-Authenticate instead, e.g. for Basicauth
(causing a user/password dialog generated by the browser).
As we have our own authentication mechanism with /Security/login,
I don't see how we could use 401. Is there some way of specifying a
custom WWW-Authenticate redirect?

2. Redirects should be done with a 3xx status code and a "Location:"
header.
I couldn't find anything on mixing "Location:" with a 4xx header,
does anybody know if thats valid? For some strange reason, a check
with "curl --head --max-redirs 0"
still shows me the 302 header, although its set to 403 right when
HTTPRequest->output() happens.
Perhaps we shouldn't redirect at all, and rather show the content of
the login page
on the denied URL directly? SEO wouldn't be a problem, as the actual
page content
is not searchbot-visible anyway, right?

Some resources:
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
http://en.wikipedia.org/wiki/HTTP_403

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> 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" [43].
>
> 10.4.4 403 Forbidden
> The server understood the request, but is refusing to fulfill it.
> Authorization will not help and the request SHOULD NOT be repeated.
> If the request method was not HEAD and the server wishes to make
> public why the request has not been fulfilled, it SHOULD describe
> the reason for the refusal in the entity. If the server does not
> wish to make this information available to the client, the status
> code 404 (Not Found) can be used instead.
>

-------
Ingo Schommer | Senior Developer
SilverStripe
http://silverstripe.com

Phone: +64 4 978 7330 ext 42
Skype: chillu23

[Sam Minnee]

This seems a little dodgy to me and I don't think that we want to
violate HTTP for the sake of testability.

Why not just assert in your FunctionalTest that response code = 302
and location = Security/login?

You could potentially put that into a boolean method on
FunctionalTest, $this->wasSecurityFailure()
You could also add custom assertions: $this->assertSecurityFailure();
and $this->assertNoSecurityFailure()

I think that we should revert r66670. It's a recipe for weird,
unexpected bugs down the line.

[Ingo Schommer]

As an afterthought, 401 Authentication with HTML Forms just made it
into the HTML5 proposal:
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#login-forms
http://ajaxian.com/archives/integrating-http-authentication-with-html-forms

[Sam Minnee]

Yeah once that's supported by a few browsers - eg the latest versions
of Firefox and Safari - it will be good to have a play with those
features, as long as legacy browsers can still be supported in some
fashion.

On Dec 3, 9:16 am, Ingo Schommer <ingo.schom...@gmail.com> wrote:
> As an afterthought, 401 Authentication with HTML Forms just made it

> into the HTML5 proposal:http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.htm...http://ajaxian.com/archives/integrating-http-authentication-with-html...