WordPress et PHP Sessions - Sécurité et performance
J'écris un plugin WordPress pour gérer une API tierce.
Cette API nécessite qu'un identificateur de session lui soit transmis afin que l'API (qui fonctionne essentiellement comme un panier tiers) sache quel élément ajouter où: à nouveau, considérez-le comme un panier.
Je souhaite stocker cet identifiant de session dans les sessions de mes utilisateurs WordPress. L'idée serait de se connecter à cette API, de demander l'identifiant de session, puis de le stocker dans la session WordPress/PHP afin que je puisse le réutiliser lorsqu'il navigue sur le site et ajouter d'autres éléments à leur panier tiers. Je reconnais que ce n’est pas idéal (pourquoi ne pas utiliser WooCommerce pour le faire directement?), Mais nous avons besoin de fonctionnalités et de données supplémentaires que seul ce tiers peut fournir.
Quoi qu'il en soit, alors que j'essayais de faire cela, j'ai trouvé ceci chez notre hôte: https://wpengine.com/support/cookies-and-php-sessions/
Ce que j'avoue, je trouve terriblement déroutant.
Selon cela, les sessions et les fonctions PHP telles que session_start() et session_id() ne sont pas conseillées et ne fonctionneront pas sur cet hôte - ... notre système ignore spécifiquement les en-têtes définissant un Cookie PHPSESSID.
Mais comme le font remarquer les docs, (si PHP sessions sont un type de cookie, quel est le problème?}
Dans mon esprit, ces docs ne répondent pas à cette question.
Ça dit:
Le plus gros conflit lors de l'utilisation de PHP Sessions est lié aux identifiants de session uniques. Comme la chaîne d’identification de chaque utilisateur est unique, cette opération "cache" tous les nouveaux utilisateurs qui visitent votre site. Ce type de système ne pourra pas évoluer avec de nombreux utilisateurs simultanés du site! Dans cet esprit, notre système ignore spécifiquement les en-têtes définissant un cookie PHPSESSID.
Ma question est la suivante: n’est-il pas vrai des sessions qu’ils préconisent, qui se font via le simple un autre cookie qui mène ensuite à une connexion à une base de données?
Ils disent ici:
En réalité, il existe un meilleur moyen de stocker les données de session utilisateur! La méthode correcte consiste à utiliser la base de données pour stocker les données de session. WooCommerce et d’autres solutions de commerce électronique ont déjà adopté cette méthode plutôt que les sessions PHP traditionnelles et utilisent également leurs propres conventions de dénomination des cookies.
Ces documents vont sur:
Au-delà des implications en termes de performances et de dimensionnement, les sessions PHP posent d’autres problèmes. Par défaut, les sessions PHP stockent les données sur le système de fichiers dans leur propre fichier unique. L'écriture de données dans un fichier est un processus d'E/S, et ces types de processus sont connus pour sauvegarder et causer une charge de serveur élevée si votre site reçoit trop d'utilisateurs simultanés. Sans compter que ce type de stockage de session ne fonctionne tout simplement pas si votre site se trouve sur une solution en cluster englobant plusieurs serveurs Web.
Pourquoi est-ce pire/meilleur que de stocker les sessions dans une base de données? N'est-ce pas aussi I/O?
J'essaie de comprendre - pourquoi la session par défaut PHP est-elle considérée comme mauvaise et la session WooCommerce comme étant bonne? J'ai examiné le le code source de WooCommerce lors de sessions , mais je n'ai pas suffisamment d'expérience dans ce domaine pour comprendre pourquoi ce qu'ils font évite les vulnérabilités mentionnées dans la documentation de l'hôte.
Plus précisément:
Il existe plusieurs vulnérabilités de sécurité centrées autour de PHP sessions. Les vulnérabilités incluent les données de session exposées, la fixation de session et le détournement de session.
Comment WooCommerce atténue-t-il cette situation là où les sessions PHP ne le sont pas? Qu'est-ce qui est conseillé pour mon cas d'utilisation?
Évidemment, je ne veux pas de sessions non sécurisées, mais développer une connexion de gestionnaire de session/cookie/base de données, comme semble le faire Woo, prendrait un certain temps. J'essaie donc de comprendre pourquoi/s'il est nécessaire de répliquer avant d'investir mon temps à éviter les sessions PHP.
Cela a très peu à voir avec wordpress, mais si cette réponse contribuera à éliminer l'utilisation de session, cela pourrait en valoir la peine ....
Les sessions sont stockées sur le disque dur du serveur. Ceci est problématique dans une scène d'hébergement partagé car le répertoire de session est très probablement lisible et accessible en écriture par tous les processus en cours d'exécution sur le serveur, pas seulement votre site. Toutes les ressources partagées sur un serveur d'hébergement partagé dépourvues de protection au niveau du système d'exploitation (telles que les autorisations de répertoire) sont au moins suspectes et vous ne devez pas les utiliser à des fins privées ou sécurisées.
permet de répéter Les sessions sont stockées sur le disque dur du serveur . Que se passe-t-il si vous utilisez un environnement multi-serveurs? Comment pourrez-vous localiser les informations de votre session? La seule façon de le faire fonctionner est d’attacher les utilisateurs à des serveurs spécifiques, ce qui n’est pas optimal.
Et encore une fois Les sessions sont stockées sur le disque dur du serveur . Si vous utilisez des sessions comme partie intégrante de votre génération HTML, cela signifie que vous ne pouvez pas mettre votre code HTML en cache.
WPEngine est un hébergement partagé dans un environnement multi-serveurs qui met en cache par défaut.
Quant à WC, comme il est dit dans ce que vous citez, ils n'utilisent pas de sessions php et inventent leur propre mécanisme en stockant des informations de session dans la base de données. C'est également une solution problématique car cela signifie qu'un trafic important risque de provoquer la fermeture du site si vous ne le faites pas avec une extrême prudence (dans ce cas, la session ne démarre que lorsqu'un utilisateur commence le processus d'achat d'un produit). Pourquoi ils le font comme cela et ne comptent pas sur les cookies, vous devrez leur demander, je suppose que le suivi des transactions incomplètes en fait partie, une autre partie est que les informations sur les cookies sur les sites http sont essentiellement publiques, et si vous voulez éviter les fuites d’informations dont vous avez besoin pour les stocker sur le serveur.
Que conseille-t-on dans votre cas? Ce sera difficile à dire sans plus de détails, mais vous devriez probablement travailler pour éliminer l'utilisation de tout ce qui ressemble à une session. HTTP n'a pas été conçu pour avoir des sessions, et il est préférable de ne pas combattre ce fait de la vie.