Changeset 7229 for django/trunk/docs/authentication.txt
- Timestamp:
- 03/12/08 01:42:09 (10 months ago)
- Files:
-
- django/trunk/docs/authentication.txt (modified) (9 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
django/trunk/docs/authentication.txt
r6924 r7229 84 84 85 85 myuser.groups = [group_list] 86 myuser.groups.add(group, group, ...)87 myuser.groups.remove(group, group, ...)86 myuser.groups.add(group, group, ...) 87 myuser.groups.remove(group, group, ...) 88 88 myuser.groups.clear() 89 89 myuser.user_permissions = [permission_list] 90 90 myuser.user_permissions.add(permission, permission, ...) 91 myuser.user_permissions.remove(permission, permission, ... ]91 myuser.user_permissions.remove(permission, permission, ...) 92 92 myuser.user_permissions.clear() 93 93 … … 381 381 382 382 .. admonition:: Calling ``authenticate()`` first 383 383 384 384 When you're manually logging a user in, you *must* call 385 385 ``authenticate()`` before you call ``login()``. ``authenticate()`` … … 388 388 documentation`_ for details), and this information is needed later 389 389 during the login process. 390 390 391 391 .. _backends documentation: #other-authentication-sources 392 392 … … 461 461 In the Django development version, ``login_required`` also takes an optional 462 462 ``redirect_field_name`` parameter. Example:: 463 463 464 464 from django.contrib.auth.decorators import login_required 465 465 … … 469 469 470 470 Again, an equivalent example of the more compact decorator syntax introduced in Python 2.4:: 471 471 472 472 from django.contrib.auth.decorators import login_required 473 473 … … 480 480 * If the user isn't logged in, redirect to ``settings.LOGIN_URL`` 481 481 (``/accounts/login/`` by default), passing the current absolute URL 482 in the query string as ``next`` or the value of ``redirect_field_name``. 482 in the query string as ``next`` or the value of ``redirect_field_name``. 483 483 For example: 484 484 ``/accounts/login/?next=/polls/3/``. … … 1120 1120 ----------------------------------------- 1121 1121 1122 Custom auth backends can provide their own permissions. 1122 Custom auth backends can provide their own permissions. 1123 1123 1124 1124 The user model will delegate permission lookup functions … … 1133 1133 The simple backend above could implement permissions for the magic admin fairly 1134 1134 simply:: 1135 1135 1136 1136 class SettingsBackend: 1137 1137 1138 1138 # ... 1139 1139 … … 1143 1143 else: 1144 1144 return False 1145 1145 1146 1146 This gives full permissions to the user granted access in the above example. Notice 1147 1147 that the backend auth functions all take the user object as an argument, and
