aboutsummaryrefslogtreecommitdiffstats
path: root/djangorestframework/authentication.py
diff options
context:
space:
mode:
authormarkotibold2011-05-18 22:13:48 +0200
committermarkotibold2011-05-18 22:13:48 +0200
commit92c015e0495b7cf39b0d0387fe6d376812a9ebef (patch)
tree81549ea10c2b2e3c550bea163e464d91f5925bb5 /djangorestframework/authentication.py
parent49d4e50342cd3a6e2dce9f61d379cb54a0c1c6b5 (diff)
downloaddjango-rest-framework-92c015e0495b7cf39b0d0387fe6d376812a9ebef.tar.bz2
Most of the actual work so far has been markup really.
Diffstat (limited to 'djangorestframework/authentication.py')
-rw-r--r--djangorestframework/authentication.py17
1 files changed, 8 insertions, 9 deletions
diff --git a/djangorestframework/authentication.py b/djangorestframework/authentication.py
index 1c5c832f..19a7aa90 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,19 @@ 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` instance or :const:`None`. [*]_
- .. [*] The authentication context *will* typically be a :obj:`User`,
+ .. [*] The authentication context *will* typically be a :obj:`User` object,
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
+ 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 +54,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 +84,7 @@ 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` object 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: