Augmenter le délai d'expiration de la session
J'ai donc une exigence que je suis sur le point de savoir comment terminer en Drupal 8.
Je vais essayer de simplifier les exigences. J'ai deux rôles. Ils sont essentiellement mutuellement exclusifs. Appelons-les "internes" et "clients".
La demande est d'avoir des clients connectés pour une période indéfinie ... appelons cela ans . Les utilisateurs internes doivent être connectés pendant une courte période, disons 1 jour, ou même juste la session. ( Remarque: je n'ai pas fait ces exigences, je les ai simplement codées ... haha )
Ma compréhension de la connexion Drupal est qu'il y a vraiment deux choses qui contrôlent cela ... il y a la durée de vie du cookie d'un utilisateur et la durée de vie de la session (sur le serveur). Si je configure le durée de vie du cookie à 1 semaine, mais la durée de vie de la session est de 1 jour, l'utilisateur sera essentiellement déconnecté après 1 jour, b/c son cookie correspondra à une session qui n'existe pas après une journée ... n'est-ce pas?
Donc, je pense que je dois commencer par la limite supérieure. Si je veux que mon utilisateur soit connecté pendant 1 an, j'ai besoin que ma session serveur soit de 1 an. L'une de mes questions est la suivante: quels sont les risques/inconvénients/etc. pour définir ma session de serveur sur 1 an? Disons que mon serveur reçoit 50 000 visites par mois. Et si ce n'est pas 1 an, et je le veux à 2 ans? Je n'arrive pas à trouver un guide définitif sur ce que devrait être la limite supérieure de la session serveur? Il semble que de nombreux facteurs pourraient également éclaircir cette session ...
Ok, donc ce qui précède est une question ... en supposant que je puisse définir la session du serveur, comment puis-je avoir la visite de la durée de vie du cookie en fonction du rôle de l'utilisateur? J'arrive au point où il semble qu'il ne soit tout simplement pas possible de modifier ce paramètre, et je devrais peut-être faire une sorte d'abonné de route et des cookies personnalisés et whanot pour détecter les utilisateurs internes, et les déconnecter lorsque je voir qu'ils sont connectés depuis trop longtemps ...
Toute aide serait très appréciée...
J'ai atteint cet objectif dans le passé pour Drupal 7 en utilisant un peu de code personnalisé.
- Définissez la durée de vie du cookie et le délai d'expiration de la session du serveur sur le plus grand des 2 nombres, dans votre cas, je suppose que c'est 2 ans.
- Écrivez un script personnalisé (par exemple dans drush) qui trouvera les sessions obsolètes et les supprimera.
Pour l'élément n ° 2, cela signifie qu'il doit trouver les utilisateurs internes ayant une courte durée de vie et supprimer leur session si le sessions.timestamp est au-delà d'une limite. Selon system.install, cette colonne contient The Unix timestamp when this session last requested a page.
La limite de votre table de sessions dépend du matériel du serveur de base de données, mais mon expérience sur un site assez grand est que vous pouvez avoir des millions d'enregistrements de sessions et ce n'est pas un énorme problème de performances. Cela dit, j'ai également constaté que l'interaction avec l'utilisateur suivait une courbe de puissance. 90% des utilisateurs qui se sont engagés et se sont fiancés l'ont fait le premier jour. 95% étaient dans la première semaine et sortir à 3 mois est passé à 98%. L'enregistrement des données de cookie au-delà de ce qui équivaut à une erreur d'arrondi n'est généralement pas super utile.
J'ai trouvé qu'essayer de faire une suppression sql directement n'évolue pas bien. Au lieu de cela, j'ai écrit une boucle qui trouverait les enregistrements à supprimer, puis exécuterais des requêtes de suppression individuelles avec une condition WHERE sid = :sid donc il utilisait une clé primaire. Cela a eu les meilleures performances tout en ayant un impact minimal. Vous pouvez même exécuter la sélection sur une base de données de réplicas en lecture pour réduire davantage l'impact sur les performances. Pour mon scénario, 1 classe d'utilisateurs qui n'avaient pas été actifs au cours de la dernière heure a été déconnectée afin que le travail s'exécute toutes les heures. L'autre classe d'utilisateurs qui a été supprimée après 3 mois serait supprimée dans un travail qui s'exécutait pendant la nuit car il effectuait plus d'opérations et avait plus d'impact sur les ressources du serveur.
Si vous avez vraiment besoin de stocker les données de session pendant 2 ans, c'est très bien. Cependant, vous pourriez envisager de stocker les données dans le cookie plutôt que dans la session. De cette façon, votre table de sessions reste légère et vous pouvez toujours faire le suivi de l'utilisateur à l'intérieur du cookie. Par exemple, si votre objectif est de suivre un canal qui a amené l'utilisateur sur le site, vous pouvez simplement stocker les informations de ce canal dans son cookie au lieu de $_SESSION. Si vous pouvez éviter de générer/conserver une session, le problème d'évolutivité disparaît.
Attention, de nombreuses araignées et bots génèrent un trafic important et se comportent mal en ce qui concerne les sessions: ils peuvent rejeter les cookies, générant effectivement une nouvelle session pour chaque demande de page si votre application le fait. Vous pouvez soit placer un réseau de blocage/mise en cache de bots devant (comme Cloudflare) ou simplement planifier d'analyser périodiquement le tableau des sessions et supprimer des sessions de ces bots en fonction de quelque chose comme l'adresse IP.
Je ne suggérerais pas memcache à cet effet, mais plutôt une base de données SQL (peut-être une instance de base de données dédiée) ou Redis. Memcache est optimisé en tant que magasin de données temporaire. Vous voulez délibérément un magasin de données persistantes, que SQL ou Redis fournissent.
Approchez-en un,
- Augmentez la durée de vie de la session et des cookies si nécessaire.
- Déplacez la session des sessions basées sur des fichiers vers Memcached. Cela peut être fait dans php.ini.
Donc, fondamentalement, vous donnez la session la plus longue à tous les utilisateurs. Et puis, vous pouvez peut-être écrire une règle ou un cronjob pour invalider les sessions des utilisateurs des rôles dont vous avez besoin d'une durée plus courte.
Approche deux, je suppose que c'est mieux https://www.drupal.org/project/persistent_login
Voir: http://www.jaspan.com/improved_persistent_login_cookie_best_practice