The Django Book：第12章 会话，用户和注册

是时候承认了:我们故意忽略了一个web开发极端重要的方面，到目前为止，我们考虑了大量未露面的匿名用户访问我们
站点页面的流量情况，这当然不正确，访问我们站点的浏览器后面是真实的人(至少有些时候是这样)，这是被忽略的一个
大问题:当Internet服务于人而不是机器时是工作的最好的，如果我们开发真正引人注目的站点时，最终我们将不得不与
浏览器后面的人打交道
不幸的是，这并不容易，HTTP被设计为无状态，即每个请求发生在一个空间里，两个请求之间没有持久化，并且我们不能
计算一个请求的每个方面(IP地址，用户代理等等)来一致的显示同一个人的连续请求
浏览器开发人员很久之前就意识到HTTP的无状态导致了web开发人员很大的麻烦，就这样cookies诞生了
cookie是一个小信息片段，浏览器存储它来代表web服务器，每次浏览器从某一服务器请求一个页面时都会把它起初接受
的cookie回传过去

Cookies
让我们看看它可能怎样工作，当你开启浏览器并键入google.com，你的浏览器像这样开始来发送一个HTTP请求到Google:
GET / HTTP/1.1
Host: google.com
...
当Google回复时，HTTP应答看起来像这样:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671;
            expires=Sun, 17-Jan-2038 19:14:07 GMT;
            path=/; domain=.google.com
Server: GWS/2.1
注意Set-Cookie头部，你的浏览器将存储这个cookie值(PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671)并在
每次你访问这个站点时回传给Google，所以下一次你访问Google时你的浏览器将传递像这样的请求:
GET / HTTP/1.1
Host: google.com
Cookie: PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671
...
然后Google可以使用这个Cookie值来知道你是早些时候访问这个站点的同一个人
例如，这个值可能是数据库存储用户信息的键，Google可以(也确实)使用它来在页面上显示你的名字

得到和设置cookies
当在Django中处理持久化时，大部分时候你想使用稍后讨论的高级session和/或用户框架，尽管如此，我们将停下来先
看看在Django中怎样读和写cookies，它将帮助你理解本章其它部分事实上怎样工作，并且如果你需要直接操作cookies
的话它将触手可得
读取已经设置的cookies是非常简单的:每个request对象都有一个类似字典的COOKIES对象，你可以使用它来读浏览器发送
到视图的任何cookies:

def show_color(request):
    if "favorite_color" in request.COOKIES:
        return HttpResponse("Your favorite color is %s" % \
            request.COOKIES["favorite_color"])
    else:
        return HttpResponse("You don't have a favorite color.")

写cookies更复杂一点，你需要使用HttpResponse对象的set_cookie()方法，这里是一个基于GET参数设置favorite_color
cookie的例子:

def set_color(request):
    if "favorite_color" in request.GET:

        # Create an HttpResponse object...
        response = HttpResponse("Your favorite color is now %s" % \
            request.GET["favorite_color"])

        # ... and set a cookie on the response
        response.set_cookie("favorite_color",
                            request.GET["favorite_color"])

    else:
        return HttpResponse("You didn't give a favorite color.")

你也可以传递一些可选参数到request.set_cookie()来控制cookie的一些方面:
Parameter        Default        Description
max_age          None           cookie持续的时间(秒)，如果为None，cookie将只持续到浏览器关闭
expires          None           cookie过期的准确日期/时间，格式应为"Wdy, DD-Mth-YY HH:MM:SS GMT"
                                如果给定值，它将覆盖max_age参数
path             "/"            cookie的合法的路径前缀，浏览器将只把cookie传递回该路径前缀下，所以你可以
                                使用它来防止cookies被传递给你的站点的其它部分，当你不控制你的站点域名的
                                顶级部分时这非常有用
domain           None           cookie的合法域名，你可以使用它来设置跨域名的cookie，例如，domain=".examp
                                le.com"将设置一个可以被www.example.com，www2.example.com和an.other.sub.
                                domain.example.com读取的cookie
                                如果设置为None，cookie将只能被设置它的域名读取
secure           False          如果设置为True，它将指示浏览器只当通过HTTPS访问页面时返回这个cookie

cookies的混合祝福
你可能注意到cookies工作的一些潜在的问题，让我们看看一些重要的:
1，Cookies本质上是自发的，浏览器不保证cookies的存储，事实上，这个行星上的每个浏览器都让你控制你的浏览器的
接受cookies的策略，如果你想看重要的cookies怎样到达web，尝试打开浏览器的"接受每个cookie"选项，甚至一个巨大
的蓝色怪物都将填充所有这些cookies!
当然，这意味着cookies上不可信任的定义，开发人员应该检查用户在信赖它们之前接受了cookies
更重要的是，你应该从不在cookies里面存储重要数据，web充满了开发人员为了某些原因在浏览器cookies里存储不可重
获的信息来使浏览器方便的恐怖故事
2，Cookies不是安全的，因为HTTP数据传输的是明文，cookies非常容易受窃听攻击，即攻击者在线上窃听可以截取
cookie并读取它，这意味着你应该从不在cookie里存储敏感信息
还有更阴险的"中间人"攻击，其中一个攻击者截取cookie并使用它来假装为另一个用户，第20章深入讨论了这种攻击现象
并给出了预防的办法
3，Cookies甚至对预定的接受者都不安全，大多数浏览器提供简易方式来编辑单独cookies的内容，并且足智多谋的用户
可以使用像mechanize的工具来手动构建HTTP请求
所以你不能在cookies里存储可窜改的敏感数据，这种情形下的标准错误是当用户登录后在cookie里存储像IsLoggedIn=1
的东西，你会对大量的站点犯这种错误而感到惊奇，只需花一秒钟就可以愚弄这些站点的"安全"系统

Django的session框架
由于这些限制和潜在的安全漏洞，很显然cookies和持久化sessions是另一个web开发里头疼的地方，当然Django的目标是
做高效的头疼杀手，所以Django带来一个为你扫平这些困难的session框架
这个session框架让你基于一个站点访问者存储和得到任意数据，它在服务器端存储数据并抽象发送和接受cookies
Cookies只使用一个哈希session ID而不是数据本身，这样可以防止大部分通常的cookie问题

允许sessions
Sessions通过一个中间件(参考第16章)和一个Django模型实现，你需要做如下事情来允许sessions:
1，编辑你的MIDDLEWARE_CLASSES设置并确认MIDDLEWARE_CLASSES包含'django.contrib.sessions.middleware.Session
Middleware'
2，确认'django.contrib.sessions'在你的INSTALLED_APPS设置里(如果你需要添加它还要允许manage.py syncdb)
通过startproject创建的默认骨架设置已经安装了这两项，所以除非你已经删除了它们，你很可能不需要改变任何东西
就可以让sessions工作
如果你不想使用sessions，你可能想从MIDDLEWARE_CLASSES删除SessionMiddleware行和从INSTALLED_APPS删除
'django.contrib.sessions'，它将只保存一个很小的过度，但是这很小的部分起作用

在视图里使用sessions
当SessionMiddleware激活后，每个HttpRequest对象--每个Django视图方法的第一个参数--将有一个session属性，它是
一个类似字典的对象，你可以像使用普通的字典一样读写它，例如，你可以在视图中做这样的事情:

# Set a session value:
request.session["fav_color"] = "blue"

# Get a session value -- this could be called in a different view,
# or many requests later (or both):
fav_color = request.session["fav_color"]

# Clear an item from the session:
del request.session["fav_color"]

# Check if the session has a given key:
if "fav_color" in request.session:
    ...

你也可以在request.session使用像keys()和items()的其它映射方法
有一些高效使用Django的sessions的简单规则:
1，在request.session使用普通的Python字符串作为字典的键(而不是integers，objects等等)，这是一个惯例，但是值
得遵循
2，以下划线开始的session字典键被Django保留作内部使用，实践中框架只使用非常少的下划线前缀的session变量，但
是除非你知道它们都是些什么(并且想跟上Django本身的更改)，最好远离它们以防Django妨碍你的app
3，不要用新的对象覆盖request.session，并且不要访问或者设置它的属性，像Python字典一样使用它
让我们看看一些快速的例子，简单的视图在用户提交一个comment后设置一个has_commented变量为True，它不让一个用户
提交一个comment多于一次:

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!')

简单的视图在站点登录一个"成员":

def login(request):
    m = members.get_object(username__exact=request.POST['username'])
    if m.password == request.POST['password']:
        request.session['member_id'] = m.id
        return HttpResponse("You're logged in.")
    else:
        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.")

注意，实践中这是登录用户的恶心的方式，下面讨论的认证框架以更健壮和有用的方式为你处理这些，这些内容只是提供
容易理解的例子

设置测试cookies
上面提到，你不能依赖每个浏览器接受cookies，所以，为了方便起见，Django提供了一个简单的方式来测试用户的浏览器
是否接受cookies，你只需在视图中调用request.session.set_test_cookie()并在后面的视图中检查requet.session.test
_cookie_worked()，而不是在同一个视图中调用
由于cookies的工作方式，这样笨拙的分离set_test_cookie()和test_cookie_worked()很必要，当你设置一个cookie，你
事实上不能分辨浏览器是否接受它，直到浏览器下一次请求
你自己使用delete_test_cookie()来清除测试cookie是良好的实践，在你验证测试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 more friendly 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')

注意，内建的登录和注销方法为你处理了这些

在视图外使用sessions
内部每个session只是在django.contrib.sessions.models定义的普通的Django模型，因为它是一个普通模型，你可以使用
普通的Django数据库API访问sessions:

>>> from django.contrib.sessions.models import Session
>>> s = Session.objects.get_object(pk='2b1189a188b44ad18c35e113ac6ceead')
>>> s.expire_date
datetime.datetime(2005, 8, 20, 13, 35, 12)

你将需要调用get_decoded()来得到准确的session数据，这是必需的，因为字典存储为一个编码的格式:

>>> s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
>>> s.get_decoded()
{'user_id': 42}

当sessions保存时
当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到数据库，设置当它没有改变时
注意只有当session被创建或修改时session cookie才被发送，如果SESSION_SAVE_EVERY_REQUEST为True，session
cookie将对每次请求发送
同样，session cookie的expires部分在每次session cookie发送时更新

浏览器长度的sessions与持久化sessions
你可能已经注意到Google发送的cookie包含expires=Sun, 17-Jan-2038 19:14:07 GMT; Cookies可以可选的包含一个过期
日期，该日期告诉浏览器什么时候删除cookie，如果一个cookie不包含过期值，浏览器将在用户关闭浏览器窗口时过期
你可以通过SESSION_EXPIRE_AT_BROWSER_CLOSE设置来控制session框架在这点上的行为
SESSION_EXPIRE_AT_BROWSER_CLOSE默认设置为False，这意味着session cookies将存储在用户的浏览器中持续
SESSION_COOKIE_AGE秒(默认为两星期，即1209600秒)，如果你不想人们每次打开浏览器时都不得不登录的话可以使用它
如果SESSION_EXPIRE_AT_BROWSER_CLOSE设置为True，Django将使用浏览器长度的cookies

其它session设置
除了已经提到的设置，还有一些其它影响Django的session框架使用cookies的设置:
Setting                    Default        Explanation
SESSION_COOKIE_DOMAIN      None           session cookies使用的域名，设置它为一个字符串，如".lawrence.com"
                                          来使用跨域名的cookies，或者设置None来使用标准cookie
SESSION_COOKIE_NAME        "sessionid"    使用sessions 的cookie名，可以是任意字符串
SESSION_COOKIE_SECURE      False          session cookie是否使用"安全"cookie，如果设置为True，cookie将被
                                          标记为"安全"，这意味着浏览器将保证cookie只通过HTTPS传送
技术细节
出于好奇，这里有一些关于session框架内部工作的技术注解:
1，session字典接受任意pickleable Python对象，参考Python内建的pickle模块文档得到更多关于这怎样工作的信息
2，Session数据存储在名为django_session的数据库表中
3，Session数据是"lazily":如果你从不访问request.session，Django不会接触那个数据库表
4，Django只在需要时传送cookie，如果你不设置任何session数据，它将不会发送session cookie(除非SESSION_SAVE_
EVERY_REQUEST设置为True)
5，Django的sessions框架是完整的，单独的和基于cookie的，它不像其它工具(PHP，JSP)一样求诸于把session IDs放在
URLs中
如果你仍然很好奇，源代码是非常直接的，你可以查看django.contrib.sessions

用户和认证
现在我们将浏览器和真实的人连接起来已经完成了一半，Sessions提供我们在多浏览器请求之间存储数据的一种方式，第
二个因素是使用这些sessions来让用户登录，当然，我们不能只信任用户所说的他们是谁，所以我们将需要认证它们
自然，Django提供工具来处理这个通常的任务(以及许多其它的)，Django的用户认证系统处理用户，组，权限和基于
cookie的用户sessions，这个系统通常称为"认证/授权"系统，这个名字解释了用户通常分两个步骤处理:
1，验证(认证)用户是她宣称的人(通常通过对数据库检查用户名和密码)
2，验证用户授权处理一些操作(通常检查权限表)
遵循这些需要，Django的认证/授权系统由一些部分组成:
1，Users
2，Permissions:二元(yes/no)标记来指示用户是否可以处理某一任务
3，Groups:把标签和权限赋予超过一个用户的通常的方式
4，Messages:排入队列和显示用户的系统消息的简单方式
5，Profiles:用自定义域扩展用户对象的机制
如果你已经使用了admin工具(第6章)，你已经看到许多这些工具，并且如果你在admin中编辑了用户或组你事实上已经在
编辑认证系统的数据库表

安装
类似于session工具，认证支持在django.contrib中绑定为Django程序，它需要安装，像session系统一样它默认已经被
安装，但是如果你删除了它，你将需要遵循这些步骤来安装它:
1，确认session框架安装了(参考上面的内容)，跟踪用户显然需要cookies，并且构建在session框架之上
2，把'django.contrib.auth'放到你的INSTALLED_APPS设置中并运行manage.py syncdb
3，确认'django.contrib.auth.middleware.AuthenticationMiddleware'在你的MIDDLEWARE_CLASSES设置中，并且它在
SessionMiddleware之后
拥有了这些安装，我们已经可以在视图方法中处理用户，你将在视图中使用来访问用户的主要接口是request.user，它是
一个表示当前登录的用户的对象，如果用户没有登录，它将被替代为一个AnonymousUser对象(参考下面更多细节)
你可以使用is_authenticated()方法很轻松的分辨用户是否登录:

if request.user.is_authenticated():
    # Do something for authenticated users.
else:
    # Do something for anonymous users.

使用用户
一旦你拥有一个用户--通常从request.user得到，但也可能通过下面讨论的一个其它方法得到--你已经得到该对象的一些
域和方法，AnonymousUser对象仿效其中一些域和方法，但是不全，所以你应该在你确认处理的是真实的用户对象之前一
直检查user.is_authenticated()
User对象的域
Field            Description
username         必需的，30个字符或更少，只允许文字和数字字符(字母，数字和下划线)
first_name       可选，30个字符或更少
last_name        可选，30个字符或更少
email            可选，E-mail地址
password         必需的，哈希的元数据秘密(Django不存储原始密码)，参看下面的"密码"部分得到更多关于这个值
is_staff         布尔值，指示用户是否可以访问admin站点
is_active        布尔值，指示用户是否可以登录，把这个标记设置为False而不是删除用户
is_superuser     布尔值，指示用户是否拥有所有的权限而不用显示的赋予它们
last_login       用户最后登录的datetime，默认设置为当前date/time
date_joined      当用户创建时的datetime，当用户创建时默认设置为当前date/time
User对象的方法
Method                   Description
is_authenticated()       对"真实的"User对象一直返回True，这是分辨用户是否认证的方式，它不暗示任何权限，并且
                         不检查用户是否active，它只指示用户成功认证
is_anonymous()           只对AnonymousUser对象返回True(对"真实"User对象返回False)，通常你应该选择使用
                         is_authenticated()方法而不是这个方法
get_full_name()          返回first_name加上last_name，使用一个空格间隔
set_password(passwd)     设置用户的密码为给定的原始密码，它会处理密码哈希，这事实上不会保存User对象
check_password(passwd)   如果给定的原始密码是该用户的正确的密码则返回True，这会在比较时处理密码哈希
get_group_permissions()  从用户所属的组返回用户拥有的权限字符串的列表
get_all_permissions()    从用户所属的组和用户的权限返回用户拥有的全息字符串的列表
has_perm(perm)           如果用户拥有该特殊权限则返回True，perm的格式为"package.codename"，如果用户inactive
                         该方法将一直返回False
has_perms(perm_list)     如果用户拥有这些特殊权限则返回True，如果用户为inactive，该方法将一直返回False
has_module_perms(appname)如果用户拥有给定appname的任一权限则返回True，如果用户inactive则一直返回False
get_and_delete_messages()返回用户的队列中的Message对象列表并从队列中删除消息
email_user(subj, msg)    发送一个e-mail给用户，这个email从DEFAULT_FROM_EMAIL设置发送，你也可以传递第3个参数
                         from_email来覆盖email的发送地址
get_profile()            返回站点特有的用户的轮廓，参考下面的轮廓部分得到更多关于此方法
最后，User对象由两个多对多域，groups和permissions，User对象可以像其它多对多域一样访问它们相关的对象:

# Set a users 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提供内建的视图方法来处理登录和注销(以及一些其它的好技巧)，但现在先让我们看看怎样"手动"登录和注销用户
Django在django.contrib.auth中提供两个方法来处理这些动作:authenticate()和login()
使用authenticate()来认证给定的用户名和密码，它有两个关键字参数，username和password，并且如果密码是合法的则
它返回一个User对象，如果密码不合法，authenticate()返回None:

>>> from django.contrib import auth authenticate
>>> user = auth.authenticate(username='john', password='secret')
>>> if user is not None:
...     print "Correct!"
... else:
...     print "Oops, that's wrong!"
Oops, that's wrong!

在视图中使用login()来登录用户，它使用一个HttpRequest对象和一个User对象并使用Django的session框架在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()不会抛出任何异常
简单方式的登录和注销
实践中，你通常不需要写你自己的登录/注销方法，auth系统带有一套视图来处理登录和注销
使用认证视图的第一步是修改你的URL配置，你将需要添加这些内容:

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默认为这些视图使用的URLs，但是你做出一点努力就可以把它们放在任
何你想要的位置，login视图默认渲染registration/login.html视图(你可以通过传递一个额外的视图参数template_na
me更改这个模板名)，这个表单需要包含一个用户名和密码域，一个简单的模板可能看起来像这样:

{% 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 }}" />
  <form action='.' method='post'>

{% endblock %}

如果用户成功登录，她将默认被重定向到/accounts/profile/，你可以通过提供一个叫next的在登录之后重定向的URL值
的hidden域来覆盖它，你也可以使用GET参数传递这个值到login视图，它将作为叫next的变量被自动添加到context中
注销视图工作起来有一点不同，默认它渲染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做下面的事情:
1，如果用户没有登录，重定向到/accounts/login/，并传递当前的查询字符串的绝对URL作为next
例如/accounts/login?next=/polls/3/
2，如果用户登录了，则正常执行视图，这样视图代码就认为用户已经登录
注意，如果你了解编程模式，这个装饰器以及下面讨论的都是"守卫"模式的例子，不是模式爱好者?

限制用户访问的测试
限制访问基于某一权限或一些其它的测试，或者为登录视图提供一个不同的位置本质上以同一方式工作
原始方式是在视图中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_test(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/'
限制访问generic views
Django用户列表最常问的一个问题是如何处理限制访问generic view，为了达到这个目的，你需要对视图做一个简单的封
装，并在你的URL配置里指定你的封装而不是generic view本身:

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

管理用户，权限和组
目前管理认证系统的最简单的方式是通过admin，第6章讨论了怎样使用Django的admin来编辑用户并控制他们的权限和访问
大多数时候你将只使用这个界面，尽管如此，当你需要绝对控制时有一些低级APIs来供你深入进去
创建用户
创建用户的基本方式是使用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对象，你也可以在保存之前继续更改它的属性:

>>> user.is_staff = True
>>> user.save()

更改密码
你可以使用set_password()更改密码:

>>> user = User.objects.get(username='john')
>>> user.set_password('goo goo goo joob')
>>> user.save()

不要直接设置password属性，除非你知道你在做什么，password事实上存储为加密的哈希并且这样不能直接编辑
更正式的，User对象的password属性是下面格式的字符串:
hashtype$salt$hash
这是哈希类型，salt和哈希本身，用美元符号分隔
hashtype是sha1(默认)或者md5，它是用来处理单向密码哈希的算法，Salt是一个用来加密原始密码来创建哈希的随机字符
串，例如:
sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4
User.set_password()和User.check_password()方法在幕后处理了设置和检查这些值
这是某种毒品吗?
不是的，加密的哈希与大麻毫无关系，它事实上是安全存储密码的通常方式，哈希是单向方法，即你可以很容易计算给定
值的哈希，但几乎不可能用一个哈希重新构造原始值
如果我们存储普通文本的密码，任何可以访问密码数据库的人都将立即知道每个人的密码，把密码存为哈希减少了危及安
全的数据值
尽管如此，可以访问密码数据库的攻击者仍然可以运行强力攻击，哈希上百万的密码并与存储值比较，这可能耗费一些时
间，但是比你想象中的要少，计算机难以置信的快
更糟糕的是，有一些公众可得到的彩虹表，即已经计算了上百万密码的哈希的数据库，使用彩虹表，攻击者可以在几秒钟
之内攻破大部分密码
添加一个salt--基本上是一个初始的随机值--到存储的哈希里面添加了另一层困难，既然salt对每个密码不同，salts也
防止了使用彩虹表，这样强迫攻击者退却--它本身通过额外的通过salt添加到哈希的熵产生更多的困难
虽然加密的哈希不是绝对的最安全的存储密码的方式，他们是安全和方便之间很好的折衷方案
处理注册
我们可以使用这些低级工具来创建允许用户注册的视图，几乎每个开发人员都希望实现不同的注册，所以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()
            return HttpResponseRedirect("/accounts/created/")
    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 %}

在模板里使用认证数据
当你使用RequestContext(参考第10章)时当前登录用户和她的权限可以在模板context得到
注意，技术上如果你使用RequestContext并且你的TEMPLATE_CONTEXT_PROCESSORS设置包含"django.core.context_proces
sors.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 }}的东西来检查用户是否拥有一些给定app的权
限，或者你可以使用像{{ 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站点使用下面的权限:
1，访问查看"添加"表单和添加对象被限制为具有该类型对象"add"权限的用户
2，访问查看更改列表，查看"更改"表单和更改对象被限制为具有该类型对象"change"权限的用户
3，访问删除对象被限制为具有该类型对象"delete"权限的用户
权限对每个类型的对象全局设定，而不是对每个对象实例，例如，可以说"Mary可以更改新闻故事"，但是当前不能说"Mary
可以更改新闻故事，但只是那些她自己创建的故事"或者"Mary只可以更改有某一状态，发表日期或ID的新闻故事"
这三个基本权限--add，create和delete--为每个有class Admin的Django模型自动创建，在幕后，当你运行manage.py sy
ncdb时这些权限添加到auth_permission数据库表
这些权限格式为"<app>.<action>_<object_name>"，即如果你有一个polls app和一个Choice模型，你将得到名为"polls.
add_choice"，"polls.change_choice"和"polls.delete_choice"的权限
注意如果你的模型没有class Admin设置，当你运行syncdb时，权限不会被创建，如果你初始化你的数据库并添加class A
dmin到模型中，你将需要再运行syncdb一次来为你安装的apps创建缺少的权限
你也可以为给定模型对象创建自定义权限，在Meta上使用permissions属性，这个例子模型创建了3个自定义权限:

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'组，并且
你可以写给他们访问你站点中只允许成员访问的权限的代码，或者给他们发送只有成员有的e-mail信息
类似于用户，管理组的最简单的方式是通过admin，尽管如此，组也只是位于django.contrib.auth.models的Django模型
所以再一次，你可以一直用底层Django数据库APIs来处理组

信息
信息系统是为给定用户将信息排入队列的轻量的方式，一个信息与一个User相关联，没有过期或时间戳的概念
信息在成功的动作之后被Django的admin使用，例如，当你创建了一个对象，你将在admin页面的顶端注意到一个"对象成功
创建"的信息，你可以使用同样的API在你自己的app里排入队列或显示信息，API很简单:
1，为了创建一个新信息，使用user.message_set.create(message='message_text')
2，为了得到/删除信息，使用user_obj.get_and_delete_messages()，它返回一个用户的队列(如果有)中的Message对象
列表并从队列中删除信息
在这个例子视图中，系统在创建一个playlist后为用户保存一条信息:

def create_playlist(request, songs):
    # Create the playlist with the given songs.
    # ...
    request.user.message_set.create(
        message="Your playlist was added successfully."
    )
    return render_to_response("playlists/create.html",
        context_instance=RequestContext(request))

当你使用RequestContext时，当前登录的用户和她的信息可以在模板context中作为模板变量{{ messages }}得到，这里
是一个显示信息的模板代码的例子:

{% if messages %}
<ul>
    {% for message in messages %}
    <li>{{ message }}</li>
    {% endfor %}
</ul>
{% endif %}

注意RequestContext在幕后调用get_and_delete_messages，所以任何信息都会被删除，甚至你不显示它们
最后，注意这个信息框架只与用户数据库里的用户工作，直接使用session框架来向匿名用户发送信息

轮廓
最后一个难题是轮廓系统，为了理解轮廓是什么东西，让我们先看看问题:
简单的，许多站点需要存储比标准的User对象更多的用户信息，为了混合这个问题，大多数站点将有不同的"额外"域
这样，Django提供了一个定义链接到给定用户的"轮廓"对象的轻量方式，这个轮廓对象可以对每个项目不同，并且甚至
可以为同一数据库服务的不同的站点处理不同的轮廓
创建一个轮廓的第一步是定义存储轮廓信息的模型，Django对该模型的唯一需求是它有一个唯一的ForeignKey到User模型
这个域必须命名为user，除了这个，你可以使用其它任何你想要的域，这里是一个任意的轮廓模型:

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

class MySiteProfile(models.Model):
    # This is the only required field
    user = models.ForeignKey(User, unique=True)

    # The rest is completely up to you...
    favorite_band = models.CharField(maxlength=100, blank=True)
    favorite_cheese = models.CharField(maxlength=100, blank=True)
    lucky_number = models.IntegerField()

下一步，你将需要告诉Django到哪里查找这个轮廓对象，你可以通过设置AUTH_PROFILE_MODULE为你的模型的标识符来做
这件事，所以，如果你的模型位于叫myapp的app，你需要将下面的内容放入你的settings文件:
AUTH_PROFILE_MODULE = "myapp.mysiteprofile"
一点完成这些，你可以通过调用user.get_profile()来访问用户的轮廓，如果AUTH_PROFILE_MODULE没定义的话这个方法
将触发SiteProfileNotAvailable异常，而且如果用户没有一个轮廓它将触发DoesNotExist异常(这时你通常将捕获这个异
常并创建一个新的轮廓)

总结
是的，session和认证系统有很多内容需要吸收，大多数时候你不需要本章描述的所有特性，但是当你需要允许用户间复
杂的交互时，所有的能力都具备就很好了
下一章我们将看看Django构建在session/user系统上的一部分:comments app，它允许你很轻松的附加注释--从匿名用户
或者认证的用户--到任意的对象

前进!向上!