Explication détaillée de Cookie et Session en python

Cet article vous apporte une explication détaillée de Cookie et Session en python. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Cookie

1. L'origine du Cookie

Tout le monde sait que le protocole HTTP est apatride.

Apatride signifie que chaque requête est indépendante. Son exécution et ses résultats ne sont pas directement liés à la requête précédente ou aux requêtes ultérieures. Elle ne sera pas directement affectée par la réponse à la requête précédente. Elle n'affectera pas directement les suivantes. demander des réponses.

Une phrase intéressante pour le décrire est que la vie, c'est comme si on la voyait pour la première fois. Pour le serveur, chaque demande est nouvelle.

L'état peut être compris comme les données générées par le client et le serveur au cours d'une session, et sans état signifie que ces données ne seront pas conservées. Les données générées au cours de la session sont ce que nous devons sauvegarder, ce qui signifie qu'elles doivent "maintenir leur état". Cookie est donc né dans un tel scénario.

2. Qu'est-ce qu'un cookie

Le cookie fait spécifiquement référence à un petit élément d'information. Il s'agit d'un ensemble de paires clé-valeur envoyées par le serveur et stockées sur le navigateur. la prochaine fois que vous visiterez le serveur, le serveur transportera automatiquement ces paires clé-valeur afin que le serveur puisse extraire des informations utiles.

3. Le principe des cookies

Le principe de fonctionnement des cookies est le suivant : le contenu est généré par le serveur, et le navigateur l'enregistre localement après réception de la demande lors de la nouvelle visite du navigateur, le navigateur créera automatiquement un cookie, afin que le serveur puisse déterminer « de qui » il s'agit grâce au contenu du cookie.

Fonctionnement des cookies dans Django

1. Obtenir Cookie

request.COOKIES['key']
request.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)

Paramètres :

• par défaut : valeur par défaut

• sel : sel de cryptage

• max_age : délai d'expiration du contrôle d'arrière-plan

Définir le cookie

2.

rep = HttpResponse(...)
rep ＝ render(request, ...)

rep.set_cookie(key,value,...)
rep.set_signed_cookie(key,value,salt='加密盐',...)

Paramètres :

• clé, clé

• valeur='', valeur

• max_age=Aucun, délai d'expiration

• expires=Aucun, délai d'expiration (IE exige l'expiration, alors définissez-le si ce n'est pas déjà fait.)

• path='/', le chemin où le cookie prend effet, / représente le chemin racine, spécial : le cookie du chemin racine est accessible par n'importe quelle page url

• domain=None , le nom de domaine où le cookie prend effet

• secure=False, transmission https

• httponly=False ne peut être que transmis par le protocole http et ne peut pas être obtenu par JavaScript (pas absolument, la capture du paquet sous-jacent peut être obtenue ou écrasée)

3. Supprimer le cookie

def logout(request):
    rep = redirect("/login/")
    rep.delete_cookie("user")  # 删除用户浏览器上之前设置的usercookie值
    return rep

Session.

Session

Bien que les cookies résolvent dans une certaine mesure le besoin de "conserver l'état", du fait que le cookie lui-même prend en charge un maximum de 4096 octets, et le cookie lui-même est enregistré sur le client, il peut être intercepté ou volé, donc un nouvel élément est nécessaire qui peut prendre en charge plus d'octets, et il est stocké sur le serveur avec une sécurité plus élevée. C'est la séance.

Le problème est que, sur la base des caractéristiques apatrides du protocole HTTP, le serveur ne sait pas du tout "qui" est le visiteur. Le cookie mentionné ci-dessus joue alors un rôle de pont.

Nous pouvons attribuer un identifiant unique au cookie de chaque client, de sorte que lorsque l'utilisateur visite, le serveur saura "qui" est le visiteur grâce au cookie. Ensuite, nous stockons des informations privées sur le serveur pendant une période de temps basée sur différents identifiants de cookies, tels que le « mot de passe du compte », etc.

En résumé : les cookies compensent les défauts de l'apatridie du HTTP, permettant au serveur de savoir "qui" est la personne qui vient. Cependant, les cookies sont stockés localement sous forme de texte et leur propre sécurité est médiocre ; Nous utilisons donc des cookies pour identifier différents utilisateurs et stockons en conséquence des informations privées et du texte dépassant 4 096 octets dans la session.

De plus, les Cookie et Session mentionnés ci-dessus sont en réalité des choses courantes et ne se limitent pas aux langages et aux frameworks.

Méthodes liées aux sessions dans Django

# 获取、设置、删除Session中数据
request.session['k1']
request.session.get('k1',None)
request.session['k1'] = 123
request.session.setdefault('k1',123) # 存在则不设置
del request.session['k1']


# 所有 键、值、键值对
request.session.keys()
request.session.values()
request.session.items()
request.session.iterkeys()
request.session.itervalues()
request.session.iteritems()

# 会话session的key
request.session.session_key

# 将所有Session失效日期小于当前日期的数据删除
request.session.clear_expired()

# 检查会话session的key在数据库中是否存在
request.session.exists("session_key")

# 删除当前会话的所有Session数据
request.session.delete()
　　
# 删除当前的会话数据并删除会话的Cookie。
request.session.flush() 
    这用于确保前面的会话数据不可以再次被用户的浏览器访问
    例如，django.contrib.auth.logout() 函数中就会调用它。

# 设置会话Session和Cookie的超时时间
request.session.set_expiry(value)
    * 如果value是个整数，session会在些秒数后失效。
    * 如果value是个datatime或timedelta，session就会在这个时间后失效。
    * 如果value是0,用户关闭浏览器session就会失效。
    * 如果value是None,session会依赖全局session失效策略。

1. Analyse du processus de session

2. Configuration de session dans Django

Django prend en charge Session par défaut et fournit 5 types de Session en interne que les développeurs peuvent utiliser.

1. 数据库Session
SESSION_ENGINE = 'django.contrib.sessions.backends.db'   # 引擎（默认）

2. 缓存Session
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'  # 引擎
SESSION_CACHE_ALIAS = 'default'                            # 使用的缓存别名（默认内存缓存，也可以是memcache），此处别名依赖缓存的设置

3. 文件Session
SESSION_ENGINE = 'django.contrib.sessions.backends.file'    # 引擎
SESSION_FILE_PATH = None                                    # 缓存文件路径，如果为None，则使用tempfile模块获取一个临时地址tempfile.gettempdir() 

4. 缓存+数据库
SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'        # 引擎

5. 加密Cookie Session
SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies'   # 引擎

其他公用设置项：
SESSION_COOKIE_NAME ＝ "sessionid"                       # Session的cookie保存在浏览器上时的key，即：sessionid＝随机字符串（默认）
SESSION_COOKIE_PATH ＝ "/"                               # Session的cookie保存的路径（默认）
SESSION_COOKIE_DOMAIN = None                             # Session的cookie保存的域名（默认）
SESSION_COOKIE_SECURE = False                            # 是否Https传输cookie（默认）
SESSION_COOKIE_HTTPONLY = True                           # 是否Session的cookie只支持http传输（默认）
SESSION_COOKIE_AGE = 1209600                             # Session的cookie失效日期（2周）（默认）
SESSION_EXPIRE_AT_BROWSER_CLOSE = False                  # 是否关闭浏览器使得Session过期（默认）
SESSION_SAVE_EVERY_REQUEST = False                       # 是否每次请求都保存Session，默认修改之后才保存（默认）

Django中Session相关设置

Django中Session相关设置

Paramètres liés à la session dans Django

3 Décorateur lié à CBV

Vue de connexion implémentée par CBV

class LoginView(View):

    def get(self, request):
        """
        处理GET请求
        """
        return render(request, 'login.html')

    def post(self, request):
        """
        处理POST请求 
        """
        user = request.POST.get('user')
        pwd = request.POST.get('pwd')
        if user == 'alex' and pwd == "alex1234":
            next_url = request.GET.get("next")
            # 生成随机字符串
            # 写浏览器cookie -> session_id: 随机字符串
            # 写到服务端session：
            # {
            #     "随机字符串": {'user':'alex'}
            # }
            request.session['user'] = user
            if next_url:
                return redirect(next_url)
            else:
                return redirect('/index/')
        return render(request, 'login.html')

Pour utiliser notre décorateur check_login ci-dessus dans la vue CBV, il existe trois manières :

à partir de django.utils.decorators import method_decorator

1. Ajouter sur get ou post. méthode de la vue CBV

from django.utils.decorators import method_decorator


class HomeView(View):

    def dispatch(self, request, *args, **kwargs):
        return super(HomeView, self).dispatch(request, *args, **kwargs)

    def get(self, request):
        return render(request, "home.html")
    
    @method_decorator(check_login)
    def post(self, request):
        print("Home View POST method...")
        return redirect("/index/")

2. Ajoutez-le sur la méthode de dispatch

from django.utils.decorators import method_decorator


class HomeView(View):

    @method_decorator(check_login)
    def dispatch(self, request, *args, **kwargs):
        return super(HomeView, self).dispatch(request, *args, **kwargs)

    def get(self, request):
        return render(request, "home.html")

    def post(self, request):
        print("Home View POST method...")
        return redirect("/index/")

car le dispatch est exécuté en premier dans la méthode CBV, donc écrire ceci équivaut à ajouter une vérification de connexion aux méthodes get et post.

3. Ajoutez-le directement à la classe view, mais method_decorator doit transmettre le paramètre de mot-clé name

Si la méthode get et la méthode post nécessitent une vérification de connexion, écrivez deux un décorateur.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!