Explication détaillée du verrouillage de session, de la concurrence et de la couverture en PHP-tutoriel php-php.cn

Explication détaillée du verrouillage de session, de la concurrence et de la couverture en PHP

小云云

Libérer： 2023-03-21 21:54:02

original

1976 Les gens l'ont consulté

Cet article vous présente principalement le verrouillage et la simultanéité de la session PHP. Les phénomènes associés incluent le blocage des requêtes, la perte de données de session et l'impossibilité de lire les données de session. J'espère que cela pourra aider tout le monde. .

Je n'arrive pas à me connecter
Un jour, j'allais me connecter à l'un de nos systèmes backend pour résoudre un bug, et je suis entré le code de vérification du mot de passe du compte avec précision. Dans ce cas, je ne parviens pas à me connecter. Après de nombreuses expériences, j'ai découvert qu'il y avait deux messages d'erreur principaux :

vérification csrf. échoué
Le code de vérification est erroné [Je jure devant les dieux du code que j'ai entré le code de vérification que j'ai vu en utilisant la demi-largeur, et dans le même ordre, sans caractères supplémentaires]

Notre systèmeNotre système est développé sur la base de phalcon 2.0 .8. Comme vous pouvez le voir, nous avons ajouté dans le champ du formulaire Domaine pour empêcher les attaques CSRF. Captcha est également activé.

<input type="hidden" 
  name="{{ security.getTokenKey() }}"
  value="{{ security.getToken() }}"/>
<img src="/login/getCaptcha" id="img-captcha"/>

Copier après la connexion

J'ai d'abord vérifié ces deux composants et j'ai constaté qu'ils stockaient tous les deux des données dans la session :

# phalcon/security.zep
# Security::getToken()
let session = <SessionInterface> dependencyInjector->getShared("session"); 
session->set(this->_tokenValueSessionID, token); 
$this->session->set(&#39;admin_get_captcha_action&#39;, $captcha);

Copier après la connexion

Ensuite, j'ai vérifié notre La mise en œuvre de la session est pour stocker des données dans Redis.

Recherche et rechercheQuel est le problème qui m'empêche de me connecter ? Puisqu'il y a un problème avec la vérification des données, commençons par les données. Je me suis connecté à la machine Redis dans notre environnement de test, j'ai exécuté Redis-cli Monitor, puis j'ai suivi le processus de connexion et j'ai trouvé le résultat comme suit (ce qui signifie) :

GET sessionId
GET sessionId
SETEX sessionId 3600 csrf=xxxx 🎜>
On peut voir :
1. Il y a deux demandes ici, l'une consiste à charger le formulaire et l'autre à générer le code de vérification. 2. Il existe une situation de « concurrence ». Ces deux requêtes doivent demander le code de vérification une fois le formulaire chargé et rendu. Autrement dit, la séquence de session doit être get->set->get->set. .Il semble que Pourquoi y a-t-il des demandes simultanées ? 3. Ce dernier SETEX n'a pas de contenu csrf, ce qui signifie qu'il écrase les données précédentes Le monde entier n'est pas bon, mais je comprends un peu quel est le problème. Quel est le problème ? C'est une longue histoire, à commencer par l'accès aux données de session PHP.

Accès aux données de session PHP

Les données de session sont codées dans une chaîne et stockées dans la mémoire [fichier, base de données, redis, memcache, etc.]. nous utilisons la session, quand allons-nous au stockage pour obtenir des données ? Quand les données sont-elles écrites en mémoire ?

La réponse à cette question peut être différente de ce que pensent certains amis. Dans une requête, PHP ne lira la mémoire qu'une seule fois, au démarrage de la session, puis n'écrira dans la mémoire qu'une seule fois, à la fin de la requête. , ou lorsque session_write_close est appelé, les données sont renvoyées dans la mémoire et la session est fermée.

Alors la question est :

1、如果一个会话，同时出现两个读写session请求，没有保证获取1-写入1-获取2-写入2，同时没有cas版本管理机制的情况下，这些并发请求就会彼此读取不到对方的写入，最后写入的会把前面请求写入的session覆盖掉。
2、如果请求是串行的，像登录页面的表单和验证码，也有可能前面的请求已经输出内容了，但是session还没写入，后面的请求就已经发起了。
锁与不锁
解决这种资源的并发一般会通过锁或版本管理来处理。但是版本管理我看不到好的方法。就聊聊锁吧。

其实锁是不大适合，有弊端的。

php的session，默认是用文件存储的，在打开session的时候，会对文件加独占锁，这样，其它请求就无法获取锁了，只能等待直到前面的锁解了。

这样保证了读取-写入，读取-写入的顺序。

其它存储器，例如mysql，可以借助select for update进行行锁。redis可以通过一个自增键，返回1的获取到锁等来实现。

这个实现的话，对数据流来说很理想，但是，对于目前这种页面大量应用ajax的情况，所有请求排队处理，将大大加大页面展现的耗时，甚至出现请求超时等不可用故障。

没有解决的解决不建议过多使用session，其一次读取一次写入的机制所引发的问题，会造成坑的存在。
在模版渲染前，或请求输出前调用session_write_close

# 立刻回写session,避免session覆盖
$eventManager = $this->view->getEventsManager();
if (!$eventManager) { 
  $eventManager = new Manager();
  $this->view->setEventsManager($eventManager);
}
$eventManager->attach("view:afterRender",function(){
  session_write_close();
});
return $this->view; 
if($login) { 
  # 立刻回写session,避免session读取不到
  $eventManager = $this->dispatcher->getEventsManager();
  if (!$eventManager) {
    $eventManager = new Manager();
    $this->dispatcher->setEventsManager($eventManager);
  }
  $eventManager->attach(&#39;dispatch:afterDispatchLoop&#39;,function(){
    session_write_close();
  });
  return $this->response->setHeader(&#39;Location&#39;, &#39;/&#39;);
}

Copier après la connexion