django Cookie和Session技术_django实践-0505cookie和session-CSDN博客

本文链接：https://blog.csdn.net/x666xwgmdfgg_/article/details/103573574

django Cookie和session技术

cookie session
上下文
中间件

cookie和session

cookie：在网站中，http请求是无状态的。也就是说即使第一次和服务器连接后并且登录成功后，第二次请求服务器依然不能知道当前请求是哪个用户。cookie的出现就是为了解决这个问题，第一次登录后服务器返回一些数据（cookie）给浏览器，然后浏览器保存在本地，当该用户发送第二次请求的时候，就会自动的把上次请求存储的cookie数据自动的携带给服务器，服务器通过浏览器携带的数据就能判断当前用户是哪个了。cookie存储的数据量有限，不同的浏览器有不同的存储大小，但一般不超过4KB。因此使用cookie只能存储一些小量的数据。
session: session和cookie的作用有点类似，都是为了存储用户相关的信息。不同的是，cookie是存储在本地浏览器，session是一个思路、一个概念、一个服务器存储授权信息的解决方案，不同的服务器，不同的框架，不同的语言有不同的实现。虽然实现不一样，但是他们的目的都是服务器为了方便存储数据的。session的出现，是为了解决cookie存储数据不安全的问题的。
cookie和session使用：web开发发展至今，cookie和session的使用已经出现了一些非常成熟的方案。在如今的市场或者企业里，一般有两种存储方式：
- 存储在服务端：通过cookie存储一个sessionid，然后具体的数据则是保存在session中。如果用户已经登录，则服务器会在cookie中保存一个sessionid，下次再次请求的时候，会把该sessionid携带上来，服务器根据sessionid在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server side session。Django把session信息默认存储到数据库中，当然也可以存储到其他地方，比如缓存中，文件系统中等。存储在服务器的数据会更加的安全，不容易被窃取。但存储在服务器也有一定的弊端，就是会占用服务器的资源，但现在服务器已经发展至今，一些session信息还是绰绰有余的。
- 将session数据加密，然后存储在cookie中。这种专业术语叫做client side session。flask框架默认采用的就是这种方式，但是也可以替换成其他形式。

登录流程：

	1. 验证用户名和密码 验证通过以后登录 同时 会将 主键或者用户名等信息存入session（加密的）
	2. 浏览器自动会将加密后的session_id发给浏览器的cookie中  
    		3. 用户下次访问 携带cookie cookie中携带session_id  
        		4. 服务器收到请求 解析header信息  解密session_id  然后跟服务器的session中的信息 进行比较 如果相同认为你就登录了

在django中操作cookie和session：

操作cookie：

设置cookie：

设置cookie是设置值给浏览器的。因此我们需要通过response的对象来设置，设置cookie可以通过response.set_cookie来设置，这个方法的相关参数如下：

key：这个cookie的key。
value：这个cookie的value。
max_age：最长的生命周期。单位是秒。
expires：过期时间。跟max_age是类似的，只不过这个参数需要传递一个具体的日期，比如datetime或者是符合日期格式的字符串。如果同时设置了expires和max_age，那么将会使用expires的值作为过期时间。
path：对域名下哪个路径有效。默认是对域名下所有路径都有效。
domain：针对哪个域名有效。默认是针对主域名下都有效，如果只要针对某个子域名才有效，那么可以设置这个属性.
secure：是否是安全的，如果设置为True，那么只能在https协议下才可用。
httponly：默认是False。如果为True，那么在客户端不能通过JavaScript进行操作。

删除cookie：

通过delete_cookie即可删除cookie。实际上删除cookie就是将指定的cookie的值设置为空的字符串，然后使用将他的过期时间设置为0，也就是浏览器关闭后就过期。

获取cookie：

获取浏览器发送过来的cookie信息。可以通过request.COOKIES来或者。这个对象是一个字典类型。比如获取所有的cookie，那么示例代码如下：

cookies = request.COOKIES
for cookie_key,cookie_value in cookies.items():
   print(cookie_key,cookie_value)

操作session：

django中的session默认情况下是存储在服务器的数据库中的，在表中会根据sessionid来提取指定的session数据，然后再把这个sessionid放到cookie中发送给浏览器存储，浏览器下次在向服务器发送请求的时候会自动的把所有cookie信息都发送给服务器，服务器再从cookie中获取sessionid，然后再从数据库中获取session数据。但是我们在操作session的时候，这些细节压根就不用管。我们只需要通过request.session即可操作。示例代码如下：

def index(request):
   request.session.get('username')
   return HttpResponse('index')

session常用的方法如下：

get：用来从session中获取指定值。
pop：从session中删除一个值。
keys：从session中获取所有的键。
items：从session中获取所有的值。
clear：清除当前这个用户的session数据。
flush：删除session并且删除在浏览器中存储的session_id，一般在注销的时候用得比较多。
set_expiry(value)：设置过期时间。
- 整形：代表秒数，表示多少秒后过期。
- 0：代表只要浏览器关闭，session就会过期。
- None：会使用全局的session配置。在settings.py中可以设置SESSION_COOKIE_AGE来配置全局的过期时间。默认是1209600秒，也就是2周的时间。
clear_expired：清除过期的session。Django并不会清除过期的session，需要定期手动的清理，或者是在终端，使用命令行python manage.py clearsessions来清除过期的session。

from datetime import timedelta
def session_view(request):
    # expires = datetime(year=2019, month=12, day=12, hour=20, minute=30, second=30)
    # expires = make_aware(expires)
    request.session['username'] = 'chengcheng999999999999999'
    request.session['id'] = '666666'
    # expires = timedelta(100)
    request.session.set_expiry(1000)
    return HttpResponse('session_view')

def get_session(request):
    username = request.session.get('username')
    userid = request.session.get('id')
    print(username)
    print(userid)
    return HttpResponse('获取session成功')

#删除session
def delete_session(request):
    res = request.session.pop('username')
    return HttpResponse(res)

修改session的存储机制：

默认情况下，session数据是存储到数据库中的。当然也可以将session数据存储到其他地方。可以通过设置SESSION_ENGINE来更改session的存储位置，这个可以配置为以下几种方案：

django.contrib.sessions.backends.db：使用数据库。默认就是这种方案。
django.contrib.sessions.backends.file：使用文件来存储session。
django.contrib.sessions.backends.cache：使用缓存来存储session。想要将数据存储到缓存中，前提是你必须要在settings.py中配置好CACHES，并且是需要使用Memcached，而不能使用纯内存作为缓存。
django.contrib.sessions.backends.cached_db：在存储数据的时候，会将数据先存到缓存中，再存到数据库中。这样就可以保证万一缓存系统出现问题，session数据也不会丢失。在获取数据的时候，会先从缓存中获取，如果缓存中没有，那么就会从数据库中获取。
django.contrib.sessions.backends.signed_cookies：将session信息加密后存储到浏览器的cookie中。这种方式要注意安全，建议设置SESSION_COOKIE_HTTPONLY=True，那么在浏览器中不能通过js来操作session数据，并且还需要对settings.py中的SECRET_KEY进行保密，因为一旦别人知道这个SECRET_KEY，那么就可以进行解密。另外还有就是在cookie中，存储的数据不能超过4k。

如果想把session存入缓存 redis中  还得设置CACHES
SESSION_ENGINE = [
    'django.contrib.sessions.backends.cache'
] 




切换到虚拟环境   pip install django-redis   在settings.py中加入下面的选项
from django_redis.cache imporrt RedisCache
from django_redis.client import DefaultClient
CACHES = {
    'default':{
        'BACKEND':'django_redis.cache.RedisCache',
        'LOCATION':"redis://127.0.0.1:6379/1",
        'OPTIONS':{
            'CLIENT_CLASS':'django_redis.client.DefaultClient'
        }
    }
}

上下文处理器

上下文处理器是可以返回一些数据，在全局模板中都可以使用。比如登录后的用户信息，在很多页面中都需要使用，那么我们可以放在上下文处理器中，就没有必要在每个视图函数中都返回这个对象。

在settings.TEMPLATES.OPTIONS.context_processors中，有许多内置的上下文处理器。这些上下文处理器的作用如下：

django.template.context_processors.debug：增加一个debug和sql_queries变量。在模板中可以通过他来查看到一些数据库查询。
django.template.context_processors.request：增加一个request变量。这个request变量也就是在视图函数的第一个参数。
django.contrib.auth.context_processors.auth：Django有内置的用户系统，这个上下文处理器会增加一个user对象。
django.contrib.messages.context_processors.messages：增加一个messages变量。
django.template.context_processors.media：在模板中可以读取MEDIA_URL。比如想要在模板中使用上传的文件，那么这时候就需要使用settings.py中设置的MEDIA_URL来拼接url。示例代码如下：

```

django.template.context_processors.static：在模板中可以使用STATIC_URL。
django.template.context_processors.csrf：在模板中可以使用csrf_token变量来生成一个csrf token。

自定义上下文处理器：

有时候我们想要返回自己的数据。那么这时候我们可以自定义上下文处理器。自定义上下文处理器的步骤如下：

你可以根据这个上下文处理器是属于哪个app，然后在这个app中创建一个文件专门用来存储上下文处理器。比如context_processors.py。或者是你也可以专门创建一个Python包，用来存储所有的上下文处理器。
在你定义的上下文处理器文件中，定义一个函数，这个函数只有一个request

参数。这个函数中处理完自己的逻辑后，把需要返回给模板的数据，通过字典的形式返回。如果不需要返回任何数据，那么也必须返回一个空的字典。示例代码如下：

def frontuser(request):
userid = request.session.get(“userid”)
userModel = models.FrontendUser.objects.filter(pk=userid).first()
if userModel:
return {‘frontuser’:userModel}
else:
return {}


# 中间件

中间件是在`request`和`response`处理过程中的一个插件。比如在`request`到达视图函数之前，我们可以使用中间件来做一些相关的事情，比如可以判断当前这个用户有没有登录，如果登录了，就绑定一个`user`对象到`request`上。也可以在`response`到达浏览器之前，做一些相关的处理，比如想要统一在`response`上设置一些`cookie`信息等。

## 自定义中间件：

中间件所处的位置没有规定。只要是放到项目当中即可。一般分为两种情况，如果中间件是属于某个`app`的，那么可以在这个`app`下面创建一个`python`文件用来存放这个中间件，也可以专门创建一个`Python`包，用来存放本项目的所有中间件。创建中间件有两种方式，一种是使用函数，一种是使用类，接下来对这两种方式做个介绍：

### 使用函数的中间件：

```python
def simple_middleware(get_response):#get_response是一个方法 
   # 这个中间件初始化的代码

   def middleware(request):
       # request到达view的执行代码

       response = get_response(request)

       # response到达浏览器的执行代码

       return response

   return middleware
 
from .models import User

def front_user_middleware(get_response): #get_response是一个方法
 #执行一些初始化的代码
 print("在这里我先执行一些初始化的代码")
 def middleware(request): #真正执行是在这里
     print("这个位置执行的是request到达view之前的代码")
     user_id = request.session.get('user_id')
     if user_id:
         try:
             user = User.objects.get(pk=user_id)
             request.front_user = user
             #将登录用户的详细信息 绑定到request对象上
         except:
             request.front_user = None
     else:
         request.front_user = None

     #上面执行的代码就是request到达view之前执行的
     response = get_response(request) #request对象上面有登录用户的详细信息
     print("以这个为界限它后边就是response到达浏览器之前执行的代码")
     return response
 return middleware

使用类的中间件：

class SimpleMiddleware(object):
      def __init__(self, get_response):
          self.get_response = get_response
          # 这个中间件初始化的代码
          def __call__(self, request):
              # request到达view之前执行的代码

              response = self.get_response(request)

              # response到达用户浏览器之前执行的代码

              return response

在写完中间件后，还需要在settings.MIDDLEWARES中配置写好的中间件才可以使用。比如我们写了一个在request到达视图函数之前，判断这个用户是否登录，如果已经登录就绑定一个user对象到request上的中间件，这个中间件放在当前项目的middlewares.users下：

def user_middleware(get_response):
      # 这个中间件初始化的代码

      def middleware(request):
          # request到达view的执行代码
          userid = request.session.get("userid")
          userModel = FrontUser.objects.filter(pk=userid).first()
          if userModel:
                  setattr(request,'frontuser',userModel)

          response = get_response(request)

          # response到达浏览器的执行代码

          return response

      return middleware

那么就可以在settings.MIDDLEWARES下做以下配置：

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'middlewares.users.user_middleware'
]

中间件的执行是有顺序的，他会根据在MIDDLEWARE中存放的顺序来执行。因此如果有些中间件是需要基于其他中间件的，那么就需要放在其他中间件的后面来执行。

Django内置的中间件：

```
django.middleware.common.CommonMiddleware
```
：通用中间件。他的作用如下：
- 限制
```
settings.DISALLOWED_USER_AGENTS
```
  中指定的请求头来访问本网站。
```
DISALLOWED_USER_AGENT
```
  是一个正则表达式的列表。示例代码如下：
```
      import re
      DISALLOWED_USER_AGENTS = [
          re.compile(r'^\s$|^$'),
          re.compile(r'.*PhantomJS.*')
      ]
```
- 如果开发者在定义url的时候，最后有一个斜杠。但是用户在访问url的时候没有提交这个斜杠，那么CommonMiddleware会自动的重定向到加了斜杠的url上去。
django.middleware.gzip.GZipMiddleware：将响应数据进行压缩。如果内容长度少于200个长度，那么就不会压缩。
django.contrib.messages.middleware.MessageMiddleware：消息处理相关的中间件。
django.middleware.security.SecurityMiddleware：做了一些安全处理的中间件。比如设置XSS防御的请求头，比如做了http协议转https协议的工作等。
django.contrib.sessions.middleware.SessionMiddleware：session中间件。会给request添加一个处理好的session对象。
django.contrib.auth.middleware.AuthenticationMiddleware：会给request添加一个user对象的中间件。
django.middleware.csrf.CsrfViewMiddleware：CSRF保护的中间件。
django.middleware.clickjacking.XFrameOptionsMiddleware：做了clickjacking攻击的保护。clickjacking保护是攻击者在自己的病毒网站上，写一个诱惑用户点击的按钮，然后使用iframe的方式将受攻击的网站（比如银行网站）加载到自己的网站上去，并将其设置为透明的，用户就看不到，然后再把受攻击的网站（比如银行网站）的转账按钮定位到病毒网站的按钮上，这样用户在点击病毒网站上按钮的时候，实际上点击的是受攻击的网站（比如银行网站）上的按钮，从而实现了在不知不觉中给攻击者转账的功能。
缓存中间件：用来缓存一些页面的。
- django.middleware.cache.UpdateCacheMiddleware。
- django.middleware.cache.FetchFromCacheMiddleware。

内置中间件放置的顺序：

SecurityMiddleware：应该放到最前面。因为这个中间件并不需要依赖任何其他的中间件。如果你的网站同时支持http协议和https协议，并且你想让用户在使用http协议的时候重定向到https协议，那么就没有必要让他执行下面一大串中间件再重定向，这样效率更高。
UpdateCacheMiddleware：应该在SessionMiddleware, GZipMiddleware, LocaleMiddleware之前。
GZipMiddleware。
ConditionalGetMiddleware。
SessionMiddleware。
LocaleMiddleware。
CommonMiddleware。
CsrfViewMiddleware。
AuthenticationMiddleware。
MessageMiddleware。
FetchFromCacheMiddleware。
FlatpageFallbackMiddleware。
RedirectFallbackMiddleware。