aboutsummaryrefslogtreecommitdiffstats
path: root/djangorestframework/authentication.py
diff options
context:
space:
mode:
authorTom Christie2011-05-19 08:49:57 +0100
committerTom Christie2011-05-19 08:49:57 +0100
commite7f8c06dbbbc9e4ae91327ee02cd8147777b17e2 (patch)
treed2a0788753c03eb438ac44d97520b132be0d9097 /djangorestframework/authentication.py
parent8c3280f9c0d73c4e2536f1d757ad457b4a8f1de7 (diff)
parent92c015e0495b7cf39b0d0387fe6d376812a9ebef (diff)
downloaddjango-rest-framework-e7f8c06dbbbc9e4ae91327ee02cd8147777b17e2.tar.bz2
Merge in marko's doc markup
Diffstat (limited to 'djangorestframework/authentication.py')
-rw-r--r--djangorestframework/authentication.py19
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: