Change HTTP status to 401 when user needs to login.

Returning a HTTP 302 is impractical for APIs when called via JavaScript.

The XMLHttpRequest specification requires that redirects are handled by
XMLHttpRequest object and therefore are not seen by the script that
called an URL that returns a 302. See http://www.w3.org/TR/2014/WD-XMLHttpRequest-20140130/#infrastructure-for-the-send()-method

I've changed the NeedsLogin exception to return HTTP 401 with the
login URL in payload and a hint in the WWW-Authenticate header which
is required by the HTTP specification for this status code.

[iannucci, 2014-02-04 18:52:49]

Good point re: XHR, I wasn't thinking that far ahead.

https://codereview.appspot.com/54850044/diff/1/framework/exceptions.py
File framework/exceptions.py (right):

https://codereview.appspot.com/54850044/diff/1/framework/exceptions.py#newcode69
framework/exceptions.py:69: self.HEADERS = {'WWW-Authenticate': 'Login at %s to
proceed.' % url}
Hm, this isn't the right format for WWW-Authenticate though? Maybe an X header?

[Andi, 2014-02-04 19:47:04]

https://codereview.appspot.com/54850044/diff/1/framework/exceptions.py
File framework/exceptions.py (right):

https://codereview.appspot.com/54850044/diff/1/framework/exceptions.py#newcode69
framework/exceptions.py:69: self.HEADERS = {'WWW-Authenticate': 'Login at %s to
proceed.' % url}
On 2014/02/04 18:52:49, iannucci wrote:
> Hm, this isn't the right format for WWW-Authenticate though? Maybe an X
header?

No, it isn't. WWW-Authenticate is a MUST for 401, but the spec for the header
doesn't fit our needs AFAICT:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.47
and the referenced spec for Basic and Digest auth
http://tools.ietf.org/html/rfc2617#section-3.2.1

I've had a look how other APIs do it. And they seem to work around this issue by
sending a 400 Bad Request (for example Twitter and Facebook) or a 403 Forbidden
(G+). Both don't match the spec for the status codes if taken literally :)

What do you think about using 403 then instead?