diff options
| author | Tom Christie | 2011-05-19 08:49:57 +0100 |
|---|---|---|
| committer | Tom Christie | 2011-05-19 08:49:57 +0100 |
| commit | e7f8c06dbbbc9e4ae91327ee02cd8147777b17e2 (patch) | |
| tree | d2a0788753c03eb438ac44d97520b132be0d9097 /djangorestframework/authentication.py | |
| parent | 8c3280f9c0d73c4e2536f1d757ad457b4a8f1de7 (diff) | |
| parent | 92c015e0495b7cf39b0d0387fe6d376812a9ebef (diff) | |
| download | django-rest-framework-e7f8c06dbbbc9e4ae91327ee02cd8147777b17e2.tar.bz2 | |
Merge in marko's doc markup
Diffstat (limited to 'djangorestframework/authentication.py')
| -rw-r--r-- | djangorestframework/authentication.py | 19 |
1 files changed, 10 insertions, 9 deletions
diff --git a/djangorestframework/authentication.py b/djangorestframework/authentication.py index 1c5c832f..7d6e2114 100644 --- a/djangorestframework/authentication.py +++ b/djangorestframework/authentication.py @@ -4,7 +4,7 @@ The :mod:`authentication` module provides a set of pluggable authentication clas Authentication behavior is provided by mixing the :class:`mixins.AuthMixin` class into a :class:`View` class. The set of authentication methods which are used is then specified by setting the -:attr:`authentication` attribute on the :class:`View` class, and listing a set of authentication classes. +:attr:`authentication` attribute on the :class:`View` class, and listing a set of :class:`authentication` classes. """ from django.contrib.auth import authenticate @@ -26,20 +26,20 @@ class BaseAuthenticaton(object): def __init__(self, view): """ - :param view: :class:`Authentication` classes are always passed the current view on creation. + :class:`Authentication` classes are always passed the current view on creation. """ self.view = view def authenticate(self, request): """ - :param request: Request to be authenticated - :rtype: :obj:`User` or None [*]_ + Authenticate the :obj:`request` and return a :obj:`User` or :const:`None`. [*]_ .. [*] The authentication context *will* typically be a :obj:`User`, but it need not be. It can be any user-like object so long as the - permissions classes on the view can handle the object and use - it to determine if the request has the required permissions or not. - + permissions classes (see the :mod:`permissions` module) on the view can + handle the object and use it to determine if the request has the required + permissions or not. + This can be an important distinction if you're implementing some token based authentication mechanism, where the authentication context may be more involved than simply mapping to a :obj:`User`. @@ -55,7 +55,7 @@ class BasicAuthenticaton(BaseAuthenticaton): def authenticate(self, request): """ Returns a :obj:`User` if a correct username and password have been supplied - using HTTP Basic authentication. Otherwise returns `None`. + using HTTP Basic authentication. Otherwise returns :const:`None`. """ from django.utils.encoding import smart_unicode, DjangoUnicodeDecodeError @@ -85,7 +85,8 @@ class UserLoggedInAuthenticaton(BaseAuthenticaton): def authenticate(self, request): """ - Returns a :obj:`User` if the request session currently has a logged in user, otherwise `None`. + Returns a :obj:`User` if the request session currently has a logged in user. + Otherwise returns :const:`None`. """ # TODO: Switch this back to request.POST, and let FormParser/MultiPartParser deal with the consequences. if getattr(request, 'user', None) and request.user.is_active: |
