第十二章 会话、用户和注册

用正常的字符串作为 key 来访问字典 request.session ， 而不是整数、对象或其它什么的。 这不是什么强硬的条规，但值得遵循。

Session 字典中以下划线开头的 key 值是 Django 内部保留 key 值。框架只会用很少的几个下划线 开头的 session 变量，除非你知道他们的具体含义，而且愿意跟上 Django的变化，否则，最好 不要用这些下划线开头的变量，它们会让 Django 搅乱你的应用。

不要用一个新对象来替换掉 request.session ，也不要存取其属性，象用普通 Python字典一样用它。

我们来看个简单的例子。这是个简单到不能再简单的例子：在用户发了一次评论后将

has_commented 设置为 True ，这是个简单（但不很安全）的、防止用户多次评论的方法。

def post_comment(request, new_comment):

if request.session.get('has_commented', False): return HttpResponse("You've already commented.")

c = comments.Comment(comment=new_comment) c.save() request.session['has_commented'] = True

return HttpResponse('Thanks for your comment!')下面是一个很简单的站点登录视图(view)：

def login(request): try:

m = Member.objects.get(username exact=request.POST['username']) if m.password == request.POST['password']:

request.session['member_id'] = m.id return HttpResponse("You're logged in.")

except Member.DoesNotExist:

return HttpResponse("Your username and password didn't match.")这是退出登录，根据 login() :

def logout(request): try:

del request.session['member_id'] except KeyError:

pass

return HttpResponse("You're logged out.")

注意

在实践中，这是很烂的用户登录方式，稍后讨论的认证(authentication )框架会帮你以更健壮和有利的方式来处理这些问题。这些非常简单的例子只是想让你知道这一切是如何工作的。

设置测试 Cookies

就像前面提到的，你不能指望所有的浏览器都可以接受 cookie，因此，Django 为了方便，也提供了检查用户浏览器是否接受 cookie 的简单方法。你只需在视图(view)中调用 request.session.set_test_cookie() ，并在后续的视图(view)、而不是当前的视图(view)中检查 request.session.test_cookie_worked() 。

虽然把 set_test_cookie() 和 test_cookie_worked() 分开的做法看起来有些笨拙，但由于

cookie 的工作方式，这无可避免。当设置一个 cookie 时候，只能等浏览器下次访问的时候，你才能知道浏览器是否接受 cookie。

检查 cookie 是否可以正常工作后，你得自己用 delete_test_cookie() 来清除它，这是个好习惯。

这是个典型例子： def login(request):

# If we submitted the form... if request.method == 'POST':

# Check that the test cookie worked (we set it below): if request.session.test_cookie_worked():

# The test cookie worked, so delete it.

request.session.delete_test_cookie()

# In practice, we'd need some logic to check username/password

# here, but since this is an example... return HttpResponse("You're logged in.")

# The test cookie failed, so display an error message. If this

# was a real site we'd want to display a friendlier message. else:

return HttpResponse("Please enable cookies and try again.")

# If we didn't post, send the test cookie along with the login form. request.session.set_test_cookie()

return render_to_response('foo/login_form.html')

注意

再次强调，内置的认证函数会帮你帮你做检查的。

在视图(View)外使用 Session

从内部来看，每个 session 都只是一个普通的 Django model（在

django.contrib.sessions.models 中定义)。每个 session 都由一个随机的 32 字节哈希串来标识，并存储于数据库中。由于这是一个普通的 model，你可以用一般的 Django 数据库 API来读取 session。

>>> from django.contrib.sessions.models import Session

>>> s = Session.objects.get(pk='2b1189a188b44ad18c35e113ac6ceead')

>>> s.expire_date

datetime.datetime(2005, 8, 20, 13, 35, 12)

你得用 get_decoded() 来读取实际的 session 数据，因为 session 字典经过了编码存储。

>>> s.session_data 'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'

>>> s.get_decoded()

{'user_id': 42}

何时保存 Session

缺省的情况下，Django 只会在 session 发生变化的时候才会存入数据库，比如说，字典赋值或删除。

# Session is modified. request.session['foo'] = 'bar'

# Session is modified. del request.session['foo']

# Session is modified. request.session['foo'] = {}

# Gotcha: Session is NOT modified, because this alters

# request.session['foo'] instead of request.session. request.session['foo']['bar'] = 'baz'

你可以设置 SESSION_SAVE_EVERY_REQUEST 为 True 来改变这一缺省行为。如果

SESSION_SAVE_EVERY_REQUEST 设置为 True ，Django 会在每次请求的时候都把 session 存到数据库中，即使没有任何改变。

注意，会话 cookie 只会在创建和修改的时候才会送出。但如果 SESSION_SAVE_EVERY_REQUEST设置为 True ，会话 cookie 会在每次请求的时候都会送出。同时，每次会话 cookie 送出的时候，其 expires 参数都会更新。

浏览器关闭即失效会话 vs. 持久会话

你可能注意到了，Google 给我们发送的cookie 中有 expires=Sun, 17-Jan-2038 19:14:07 GMT;

cookie 可以有过期时间，这样浏览器就知道什么时候可以删除 cookie 了。如果 cookie 没有设置过期时间，当用户关闭浏览器的时候，cookie 就自动过期了。你可以改变

SESSION_EXPIRE_AT_BROWSER_CLOSE 的设置来控制 session 框架的这一行为。

缺省情况下， SESSION_EXPIRE_AT_BROWSER_CLOSE 设置为 False ，这样，会话 cookie 可以在用户浏览器中保持有效达 SESSION_COOKIE_AGE 秒（缺省设置是两周，即 1,209,600 秒）。如果你不想用户每次打开浏览器都必须重新登陆的话，用这个参数来帮你。

如果 SESSION_EXPIRE_AT_BROWSER_CLOSE 设置为 True ，当浏览器关闭时，Django 会使

cookie 失效。

其他的 Session 设置

除了上面提到的设置，还有一些其他的设置可以影响 Django session 框架如何使用 cookie，详见表 12-2.

技术细节

如果你还是好奇的话，下面是一些关于 session 框架内部工作方式的技术细节：

session 字典和普通 Python 对象一样，支持序列化，详见 Python 文档中内置 pickle 模块的部分。

Session 数据存在数据库表 django_session 中

Session 数据在需要的时候才会读取，如果你从不使用 request.session ， Django 不会动相关数据库表的一根毛。

Django 只在需要的时候才送出 cookie。如果你压根儿就没有设置任何会话数据，它不会 送出会话 cookie(除非 SESSION_SAVE_EVERY_REQUEST 设置为 True )

Django session 框架完全而且只能基于 cookie，不会，不会后退到把会话 ID 编码在 URL 中。

（像某些工具(PHP,JSP)那样）

这是一个有意而为之的设计，把session 放在URL 中不只是难看，更重要的是这让你的站点 很容易受到攻击——通过 Referer header 进行 session ID”窃听”而实施的攻击。

如果你还是好奇，阅读源代码是最直接办法，详见 django.contrib.sessions 。

用户与 Authentication

现在，我们通过浏览器连接真实用户的目标已经完成一半了。通过 session，我们可以在多次浏览器请求中保持数据， 接下来的部分就是用 session 来处理用户登录了。当然，不能仅凭用户的一面之词，我们就相信，所以我们需要认证。

当然了，Django 也提供了工具来处理这样的常见任务（就像其他常见任务一样）。Django 用户认证系统处理用户帐号，组，权限以及基于 cookie 的用户会话。这个系统一般被称为 auth/auth (认证与授权)系统，这个系统的名称同时也表明了用户常见的两步处理。我们需要

1. 验证 (认证) 用户是否是他所宣称的用户(一般通过查询数据库验证其用户名和密码)

2. 验证用户是否拥有执行某种操作的 授权 (通常会通过检查一个权限表来确认)根据这些需求，Django 认证/授权 系统会包含以下的部分：

用户 : 在网站注册的人

权限 : 用于标识用户是否拥有某种操作的二进制(yes/no)标志

组 :一种可以将标记和权限应用于多个用户的常用方法

Messages : 向用户显示队列式的系统消息的常用方法

Profiles : 通过自定义字段扩展用户对象的机制

如果你已经用了 admin 工具(详见第 6 章)，就会看见这些工具的大部分。如果已经用了 admin工具来编辑用户和组，你实际上就已经在编辑认证系统中数据库表。

打开认证支持

像 session 工具一样，认证支持也是一个 Django 应用，放在 django.contrib 中，所以也需要安装。与 session 系统相似，它也是缺省安装的，但如果它已经被删除了，通过以下步骤也能重新安装上：

1. 根据本章早前的部分确认已经安装了 session 框架，需要确认用户使用 cookie，这样

   sesson 框架才能正常使用。

2. 将 'django.contrib.auth' 放在你的 INSTALLED_APPS 设置中，然后运行 manage.py syncdb

3. 确认 SessionMiddleware 后面的 MIDDLEWARE_CLASSES 设置中包含 'django.contrib.auth.middleware.AuthenticationMiddleware'

这样安装后，我们就可以在视图(view)的函数中用处理 user 了。在视图中存取 users，主要用 request.user ；这个对象表示当前已登录的用户，如果用户还没登录，这就是一个 匿名对象(细节见下)

你可以很容易的通过 is_authenticated() 方法来判断一个用户是否已经登录了 if request.user.is_authenticated():

# Do something for authenticated users.

else:

# Do something for anonymous users.

使用 User 对象

User 实例一般从 request.user ，或是其他下面即将要讨论到的方法取得，它有很多属性和方法。 AnonymousUser 对象模拟了 部分 的接口，但不是全部，在把它当成真正的 user 对象 使用前，你得检查一下 user.is_authenticated()

最后， User 对象有两个多对多的属性： groups 和 permissions 。 User 对象可以 象使用其他多对多属性的方法一样使用它们。

# Set a user's groups: myuser.groups = group_list

# Add a user to some groups: myuser.groups.add(group1, group2,...)

# Remove a user from some groups: myuser.groups.remove(group1, group2,...)

# Remove a user from all groups: myuser.groups.clear()

# Permissions work the same way myuser.permissions = permission_list

myuser.permissions.add(permission1, permission2, ...) myuser.permissions.remove(permission1, permission2, ...) myuser.permissions.clear()

登录和退出

Django 提供内置的视图(view)函数用于处理登录和退出 (以及其他奇技淫巧)，但在开始前，我们来看看如何手工登录和退出，Django 在 django.contrib.auth 中提供了两个函数来处理这些事情—— authenticate() 和 login() 。

认证给出的用户名和密码，使用 authenticate() 函数。它接受两个参数，用户名 username和 密码 password ，并在密码对用给出的用户名是合法的情况下返回一个 User 对象。当给出的密码不合法的时候 authenticate() 函数返回 None ：

>>> from django.contrib import auth

>>> user = auth.authenticate(username='john', password='secret')

>>> if user is not None:

... print "Correct!"

... else:

... print "Oops, that's wrong!"

authenticate() 只是验证一个用户的证书而已。而要登录一个用户，使用 login() 。该函 数接受一个 HttpRequest 对象和一个 User 对象作为参数并使用 Django 的会话（ session ）框架把用户的 ID 保存在该会话中。

下面的例子演示了如何在一个视图中同时使用 authenticate() 和 login() 函数： from django.contrib import auth

def login(request):

username = request.POST['username'] password = request.POST['password']

user = auth.authenticate(username=username, password=password) if user is not None and user.is_active:

# Correct password, and the user is marked "active" auth.login(request, user)

# Redirect to a success page.

return HttpResponseRedirect("/account/loggedin/") else:

# Show an error page

return HttpResponseRedirect("/account/invalid/")

注销一个用户，在你的视图中使用 django.contrib.auth.logout() 。该函数接受一个

HttpRequest 对象作为参数，没有返回值。 from django.contrib import auth

def logout(request): auth.logout(request)

# Redirect to a success page.

return HttpResponseRedirect("/account/loggedout/")注意，即使用户没有登录， logout() 也不会抛出任何异常。

在实际中，你一般不需要自己写登录/登出的函数；认证系统提供了一系例视图用来处理登录和登出。

使用认证视图的第一步是把它们写在你的 URLconf 中。 你需要这样写： from django.contrib.auth.views import login, logout

urlpatterns = patterns('',

# existing patterns here... (r'^accounts/login/$', login), (r'^accounts/logout/$', logout),

)

/accounts/login/ 和 /accounts/logout/ 是 Django 提供的视图的默认 URL。

缺省情况下， login 视图渲染 registragiton/login.html 模板(可以通过视图的额外参数

template_name 修改这个模板名称)。这个表单必须包含 username 和 password 域。如下示例：

{% extends "base.html" %}

{% block content %}

{% if form.errors %}

<p class="error">Sorry, that's not a valid username or password</p>

{% endif %}

<form action='.' method='post'>

<label for="username">User name:</label>

<input type="text" name="username" value="" id="username">

<label for="password">Password:</label>

<input type="password" name="password" value="" id="password">

<input type="submit" value="login" />

<input type="hidden" name="next" value="{{ next|escape }}" />

<form action='.' method='post'>

{% endblock %}

如果用户登录成功，缺省会重定向到 /accounts/profile 。表单中有一个 hidden 域叫 next ，可以用在登录后指定 url。也可以把这个值（指定的 url）作为 GET 参数传递给 login 视图， 并且会作为 next 变量添加到 context 中。

logout 视图有一些不同。缺省的它渲染 registration/logged_out.html 模板（这个视图一般包含你已经成功退出的信息）。视图中还可以包含一个参数 next_page 用于退出后重定向。

限制已登录用户的访问

有很多原因需要控制用户访问站点的某部分。

一个简单原始的限制方法是检查 request.user.is_authenticated() ,然后重定向到登陆页面：

from django.http import HttpResponseRedirect def my_view(request):

if not request.user.is_authenticated():

return HttpResponseRedirect('/login/?next=%s' % request.path)

# ...

或者显示一个出错信息： def my_view(request):

if not request.user.is_authenticated():

return render_to_response('myapp/login_error.html')

# ...

作为一个快捷方式, 你可以使用便捷的 login_required 修饰符: from django.contrib.auth.decorators import login_required

@login_required

def my_view(request):

# ...

login_required 做下面的事情:

如果用户没有登录, 重定向到 /accounts/login/ , 把当前绝对 URL 作为 next 在查询字符串中传递过去, 例如: /accounts/login/?next=/polls/3/ .

如果用户已经登录, 正常地执行视图函数. 视图代码就可以假定用户已经登录了.对通过测试的用户限制访问

限制访问可以基于某种权限，某些检查或者为 login 视图提供不同的位置，这些实现方式大致相同

一般的方法是直接在视图的 request.user 上运行检查。例如，下面视图检查用户登陆并是否有 polls.can_vote 的权限：

def vote(request):

if request.user.is_authenticated() and request.user.has_perm('polls.can_vote')):

# vote here else:

return HttpResponse("You can't vote in this poll.")

并且 Django 有一个称为 user_passes_test 的简洁方式。它根据情况使用参数并且产生特殊装饰符。

def user_can_vote(user):

return user.is_authenticated() and user.has_perm("polls.can_vote")

@user_passes_text(user_can_vote, login_url="/login/") def vote(request):

# Code here can assume a logged-in user with the correct permission.

...

user_passes_test 使用一个必需的参数：一个可调用的方法，它存在 User 对象并当此用户允许查看该页面时返回 True 。 注意 user_passes_test 不会自动检查 User 是否认证，你应该自己做这件事。

例子中我们也展示了第二个可选的参数 login_url ，它让你指定你的登录页面的 URL（默认为 /accounts/login/ ）。

既然检查用户是否有一个特殊权限是相对常见的任务，Django 为这种情形提供了一个捷径：

permission_required() 装饰器 使用这个装饰器，前面的例子可以这样写: from django.contrib.auth.decorators import permission_required

@permission_required('polls.can_vote', login_url="/login/") def vote(request):

# ...

注意, permission_required() 也有一个可选的 login_url 参数, 这个参数默认为

'/accounts/login/' 。限制通用视图的访问

在 Django 用户邮件列表中问到最多的问题是关于对通用视图的限制性访问。为实现这个功能，你需要自己包装视图，并且在 URLconf 中，将你自己的版本替换通用视图：

from dango.contrib.auth.decorators import login_required from django.views.generic.date_based import object_detail

@login_required

def limited_object_detail(*args, **kwargs): return object_detail(*args, **kwargs)

当然, 你可以用任何其他限定修饰符来替换 login_required 。

管理 Users, Permissions 和 Groups

管理认证系统最简单的方法是通过管理界面。 第六章讨论了怎样使用 Django 的管理界面来编辑用户和控制他们的权限和可访问性，并且大多数时间你都会只使用这个界面。

然而，当你需要绝对的控制权的时候，有一些低层 API 需要深入专研，我们将在下面的章节中讨论它们。

创建用户

使用 create_user 辅助函数创建用户:

>>> from django.contrib.auth.models import User

>>> user = User.objects.create_user(username='john',

... email='jlennon@beatles.com',

... password='glass onion')

在这里， user 是 User 类的一个实例，准备用于向数据库中存储数据。 create_user() 函数并没有在数据库中创建记录，在保存数据之前，你仍然可以继续修改它的属性值。

>>> user.is_staff = True

>>> user.save()修改密码

你可以使用 set_password() 来修改密码：

>>> user = User.objects.get(username='john')

>>> user.set_password('goo goo goo joob')

>>> user.save()

除非你清楚的知道自己在做什么，否则不要直接修改 password 属性。其中保存的是密码的

加入 salt 的 hash 值 ，所以不能直接编辑。

一般来说， User 对象的 password 属性是一个字符串，格式如下： hashtype$salt$hash

这是哈希类型，salt 和哈希本身，用美元符号（$）分隔。

hashtype 是 sha1 （默认）或者 md5 ，它是用来处理单向密码哈希的算法，Salt 是一个用来加密原始密码来创建哈希的随机字符串，例如:

sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4

User.set_password() 和 User.check_password() 函数在后台处理和检查这些值。一个加入 salt 的哈希算法是某种毒品吗？

不是，一个 加入 salt 值的哈希算法 与毒品完全无关；事实上它提供了一种通用的方法来保证密码存储的安全。一次 哈希 是一次单向的密写过程，你能容易地计算出一个给定值的哈希码，但是几乎不可能从一个哈希码解出它的原值。

如果我们以普通文本存储密码,任何能进入数据库的人都能轻易的获取每个人的密码。使用哈希方式来存储密码相应的减少了数据库泄露密码的可能。

然而，攻击者仍然可以使用 暴力破解 使用上百万个密码与存储的值对比来获取数据库密码，这需要花一些时间，但是智能电脑惊人的速度超出了你的想象

更糟糕的是我们可以公开地得到 rainbow tables （一种暴力密码破解表）或预备有上百万哈希密码值的数据库。使用 rainbow tables 可以在几秒之内就能搞定最复杂的一个密码。

在存储的 hash 值的基础上，加入 salt 值（一个随机值），增加了密码的强度，使得破解更加困难。因为每个密码的 salt 值都不相同，这也限制了 rainbow table 的使用，使得攻击者只能使用最原始的暴力破解方法。而加入的 salt 值使得 hash 的熵进一步获得增加，使得暴力破解的难度又进一步加大。

加入 salt 值得 hash 并不是绝对安全的存储密码的方法，然而在安全和方便之间有很大的中间地带需要我们来做决定。

处理注册

我们可以使用这些底层工具来创建允许用户注册的视图。最近每个开发人员都希望实现各自不同的注册方法，所以 Django 把写一个注册试图的工作留给了你。幸运的是，这很容易。

作为这个事情的最简化处理, 我们可以提供一个小视图, 提示一些必须的用户信息并创建这些用户. Django 为此提供了可用的内置表单, 在下面这个例子中很好地使用了:

from django import oldforms as forms

from django.http import HttpResponseRedirect from django.shortcuts import render_to_response

from django.contrib.auth.forms import UserCreationForm

def register(request):

form = UserCreationForm()

if request.method == 'POST': data = request.POST.copy()

errors = form.get_validation_errors(data) if not errors:

new_user = form.save(data)

return HttpResponseRedirect("/books/")

else:

data, errors = {}, {}

return render_to_response("registration/register.html", { 'form' : forms.FormWrapper(form, data, errors)

})

这个表单构想了一个叫 registration/register.html 的模板. 这里是一个这个模板的可能的样子的例子:

{% extends "base.html" %}

{% block title %}Create an account{% endblock %}

{% block content %}

<h1>Create an account</h1>

<form action="." method="post">

{% if form.error_dict %}

<p class="error">Please correct the errors below.</p>

{% endif %}

{% if form.username.errors %}

{{ form.username.html_error_list }}

{% endif %}

<label for="id_username">Username:</label> {{ form.username }}

{% if form.password1.errors %}

{{ form.password1.html_error_list }}

{% endif %}

<label for="id_password1">Password: {{ form.password1 }}

{% if form.password2.errors %}

{{ form.password2.html_error_list }}

{% endif %}

<label for="id_password2">Password (again): {{ form.password2 }}

<input type="submit" value="Create the account" />

</label>

{% endblock %}备注

在本书出版之时, django.contrib.auth.forms.UserCreationForm 是一个 oldforms 表单.参看 http://www.djangoproject.com/documentation/0.96/forms/ 可以获取有关

oldforms 的详细信息. 转换到有关 newforms 的内容在第 7 章中将会讲述, newforms 功能将会在不远的将来完成.

在模板中使用认证数据

当前登入的用户以及他（她）的权限可以通过 RequestContext 在模板的 context 中使用（详见第 10 章）。

备注

从技术上来说，只有当你使用了 RequestContext 并且 TEMPLATE_CONTEXT_PROCESSORS 设置包含了 "django.core.context_processors.auth" （默认情况就是如此）时，这些变量才能在模板 context 中使用。更详细的内容，也请参考第 10 章。

当使用 RequestContext 时, 当前用户 (是一个 User 实例或一个 AnonymousUser 实例)存储在模板变量 {{ user }} 中:

{% if user.is_authenticated %}

<p>Welcome, {{ user.username }}. Thanks for logging in.</p>

{% else %}

<p>Welcome, new user. Please log in.</p>

{% endif %}

这些用户的权限信息存储在 {{ perms }} 模板变量中。这是一个在模板中使用很方便的代理，其中包含一些权限相关函数的简写。

你有两种方式来使用 perms 对象。你可以使用类似于 {{ perms.polls }} 的形式来检查，对于某个特定的应用，一个用户是否具有 任意 权限；你也可以使用

{{ perms.polls.can_vote }} 这样的形式，来检查一个用户是否拥有特定的权限。这样你就可以在模板中的 {% if %} 语句中检查权限:

{% if perms.polls %}

<p>You have permission to do something in the polls app.</p>

{% if perms.polls.can_vote %}

<p>You can vote!</p>

{% endif %}

{% else %}

<p>You don't have permission to do anything in the polls app.</p>

{% endif %}

其他一些功能：权限，组，消息和档案

在认证框架中还有其他的一些功能。我们会在接下来的几个部分中进一步地了解它们。

权限

权限可以很方便地标识用户和用户组可以执行的操作。它们被 Django 的 admin 管理站点所使用，你也可以在你自己的代码中使用它们。

Django 的 admin 站点如下使用权限：

只有设置了 add 权限的用户才能使用添加表单，添加对象的视图。

只有设置了 change 权限的用户才能使用变更列表，变更表格，变更对象的视图。

只有设置了 delete 权限的用户才能删除一个对象。

权限是根据每一个类型的对象而设置的，并不具体到对象的特定实例。例如，我们可以允许

Mary 改变新故事，但是目前还不允许设置 Mary 只能改变自己创建的新故事，或者根据给定的状态，出版日期或者 ID 号来选择权限。

这三个基本权限：添加，变更和删除，会被自动添加到所有的 Django 模型中，只要改模型包含 class Admin 。当你执行 manage.py syncdb 的时候，这些就被自动添加到

auth_permission 数据表中。

权限以 "<app>.<action>_<object_name>" 的形式出现。如果你有一个 polls 的应用，包含一个 Choice 模型，你就有以下三个权限，分别叫做 "polls.add_choice" ， "polls.change_choice" ，和 "polls.delete_choice" 。

注意，如果当你运行 syncdb 时，模型中没有包含 class Admin ，该模型对应的权限就不会被创建。如果你在初始化数据库以后，又在自己的模型中加入了 class Admin ，你就需要重新运行 syncdb 来为应用加入权限。

你也可以通过设置 Meta 中的 permissions 属性，来为给定的模型定制权限。下面的例子创建了三个自定义的权限：

class USCitizen(models.Model):

# ...

class Meta:

permissions = (

# Permission identifier human-readable permission name ("can_drive", "Can drive"),

("can_vote", "Can vote in elections"),

("can_drink", "Can drink alcohol"),

)

当你运行 syncdb 时，额外的权限才会被加入；你需要自己在视图中添加权限相关的代码。

就跟用户一样，权限也就是 Django 模型中的 django.contrib.auth.models 。因此如果你愿意，你也可以通过 Django 的数据库 API 直接操作权限。

组

组提供了一种通用的方式来让你按照一定的权限规则和其他标签将用户分类。一个用户可以隶属于任何数量的组。

在一个组中的用户自动获得了赋予该组的权限。例如， Site editors 组拥有

can_edit_home_page 权限，任何在该组中的用户都拥有这个权限。

组也可以通过给定一些用户特殊的标记，来扩展功能。例如，你创建了一个 'Special users'组，并且允许组中的用户访问站点的一些 VIP 部分，或者发送 VIP 的邮件消息。

和用户管理一样，admin 接口是管理组的最简单的方法。然而，组也就是 Django 模型 django.contrib.auth.models ，因此你可以使用 Django 的数据库 API，在底层访问这些组。

消息

消息系统会为给定的用户接收消息。每个消息都和一个 User 相关联。其中没有超时或者时间戳的概念。

在每个成功的操作以后，Django 的 admin 管理接口就会使用消息机制。例如，当你创建了一个对象，你会在 admin 页面的顶上看到 The object was created successfully 的消息。

你也可以使用相同的 API 在你自己的应用中排队接收和现实消息。API 非常地简单：

要创建一条新的消息，使用 user.message_set.create(message='message_text') 。

要获得/删除消息，使用 user.get_and_delete_messages() ，这会返回一个 Message对象的列表，并且从队列中删除返回的项。