Django 会话、用户和注册

。因此不能在cookies中存储可能会被篡改的敏感数据。 在cookies中存储 IsLoggedIn=1 ，以标识用户已经登录。 犯这类错误的站点数量多的令人难以置信； 绕过这些网站的安全系统也是易如反掌。Django的 Session 框架由于存在的限制与安全漏洞，cookies和持续性会话已经成为Web开发中令人头疼的典范。 好消息是，Django的目标正是高效的“头疼杀手”，它自带的session框架会帮你搞定这些问题。你可以用session 框架来存取每个访问者任意数据， 这些数据在服务器端存储，并对cookie的收发进行了抽象。 Cookies只存储数据的哈希会话ID，而不是数据本身，从而避免了大部分的常见cookie问题。下面我们来看看如何打开session功能，并在视图中使用它。打开 Sessions功能Sessions 功能是通过一个中间件(参见第17章)和一个模型(model)来实现的。 要打开sessions功能，需要以下几步操作：编辑 MIDDLEWARE_CLASSES 配置，确保 MIDDLEWARE_CLASSES 中包含'django.contrib.sessions.middleware.SessionMiddleware'。确认 INSTALLED_APPS 中有 'django.contrib.sessions' (如果你是刚打开这个应用，别忘了运行manage.py syncdb )如果项目是用 startproject 来创建的，配置文件中都已经安装了这些东西，除非你自己删除，正常情况下，你无需任何设置就可以使用session功能。如果不需要session功能，你可以删除 MIDDLEWARE_CLASSES 设置中的 SessionMiddleware 和 INSTALLED_APPS 设置中的 'django.contrib.sessions' 。虽然这只会节省很少的开销，但积少成多啊。在视图中使用SessionSessionMiddleware 激活后，每个传给视图(view)函数的第一个参数HttpRequest 对象都有一个 session 属性，这是一个字典型的对象。 你可以象用普通字典一样来用它。 例如，在视图(view)中你可以这样用：# 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: ...其他的映射方法，如 keys() 和 items() 对 request.session 同样有效：下面是一些有效使用Django sessions的简单规则：用正常的字符串作为key来访问字典 request.session ， 而不是整数、对象或其它什么的。Session字典中以下划线开头的key值是Django内部保留key值。 框架只会用很少的几个下划线 开头的session变量，除非你知道他们的具体含义，而且愿意跟上Django的变化，否则，最好 不要用这些下划线开头的变量，它们会让Django搅乱你的应用。比如，不要象这样使用_fav_color 会话密钥(session key)：request.session['_fav_color'] = 'blue' # Don't do this!不要用一个新对象来替换掉 request.session ，也不要存取其属性。 可以像Python中的字典那样使用。 例如：request.session = some_other_object # Don't do this!request.session.foo = 'bar' # Don't do this!我们来看个简单的例子。 这是个简单到不能再简单的例子：在用户发了一次评论后将has_commented设置为True。 这是个简单（但不很安全）的、防止用户多次评论的方法。def post_comment(request): if request.method != 'POST': raise Http404('Only POSTs are allowed') if 'comment' not in request.POST: raise Http404('Comment not submitted') if request.session.get('has_commented', False): return HttpResponse("You've already commented.") c = comments.Comment(comment=request.POST['comment']) c.save() request.session['has_commented'] = True return HttpResponse('Thanks for your comment!')下面是一个很简单的站点登录视图(view)：def login(request): if request.method != 'POST': raise Http404('Only POSTs are allowed') try: m = Member.objects.get(username=request.POST['username']) if m.password == request.POST['password']: request.session['member_id'] = m.id return HttpResponseRedirect('/you-are-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() 来清除它，这是个好习惯。 在你证实了测试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