why does SessionAuthentication returns 403 for unauthenticated requests?

[Jacob G]

Why does SessionAuthentication returns 403 for unauthenticated requests? It would seem that it should return 401, and only 403 if authenticated by unauthorized.

[Tom Christie]

RFC2616 specifies that an HTTP 401 response *must* include a www-authenticate header, that contains a challenge that the client is expected to respond to in an 'Authorization:' header, such as Basic, Digest, Token etc...

Unlike automated token-type authentication types, session authentication does not use an authorization header, being driven instead by a standard user login.  Accordingly, HTTP 401 is not an appropriate response to session authenticated APIs.

This is *slightly* covered in the docs, here:

http://django-rest-framework.org/api-guide/authentication.html#unauthorized-and-forbidden-responses

Hope that helps,

  Tom

[Jacob Gur]

Thanks Tom for the reply.

I understand your reply and reasoning. I haven't checked other major web sites to see what they do, but for Ajax-driven API's, it's important to distinguish between the unauthorized and forbidden. For example, if a user is logged into a protected web site which uses Ajax, and they leave the web page open for a log time, then I want future activity to return 401. Then my client script code can easily catch an 401's and redirect the parent web page to a login page. 403 would not do that; it would just fail.

I created a custom authenticator like this to basically do what I want:

class SessionAuthentication(authentication.SessionAuthentication):

    def authenticate_header(self, request):

        return 'session'

--
You received this message because you are subscribed to a topic in the Google Groups "Django REST framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-rest-framework/CVpTf6pCNMk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-rest-fram...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Tom Christie]

FWIW. One option that would be RFC compliant would be to distinguish between the two cases in the body of the response. Eg: {'detail': 'login required'}

You received this message because you are subscribed to the Google Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-rest-fram...@googlegroups.com.

[Jacob Gur]

Thanks, I thought about that. I guess I'm not full hearted that I like the RFC behavior, and I'm considering to disobey it since it's not a publicly documented API. But I might do what you recommend.

[Andrey Antukh]

Hi!

I understand, rest-framework mut be compliant with rfc, but if you don't like rfc approach, you can monky patch APIView for enable http 401 requests: https://gist.github.com/niwibe/6499135

(I have same problem that you)

;)

Andrey

2013/9/8 Jacob Gur <ja...@fareclock.com>

--
Andrey Antukh - Андрей Антух - <ni...@niwi.be>
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

[Tom Christie]

Hey Andrey,

  Worth noting that your monkey patch approach, won't need to be monkey patching for much longer.  We've now got customizable exception handling in 'master', thanks to some great work during the DjangoCon sprints by Andy Freeland.

See the incoming docs, here...

https://github.com/tomchristie/django-rest-framework/blob/master/docs/api-guide/exceptions.md#custom-exception-handling

Will be out with the next release.

[Andrey Antukh]

Hi Tom!

It seems very very nice. Great work of Andy. I will remove the monkey patch from my projects when new release is out.

;)

Andrey

2013/9/9 Tom Christie <t...@tomchristie.com>