Si j'avais un utilisateur connecté sur mon site, ayant son identifiant stocké $_SESSION, et depuis son navigateur, il cliquait sur un bouton «Enregistrer» qui ferait une demande AJAX au serveur. Les $_SESSIONcookies et lui seront-ils conservés dans cette demande et puis-je compter en toute sécurité sur la présence de l'identifiant dans le $_SESSION?
Réponses:
La réponse est oui:
Les sessions sont gérées côté serveur. En ce qui concerne le serveur, il n'y a aucune différence entre une requête AJAX et une requête de page normale. Ce sont tous les deux des requêtes HTTP et ils contiennent tous les deux des informations sur les cookies dans l'en-tête de la même manière.
Du côté client, les mêmes cookies seront toujours envoyés au serveur qu'il s'agisse d'une requête régulière ou d'une requête AJAX. Le code Javascript n'a pas besoin de faire quoi que ce soit de spécial ou même d'être conscient de ce qui se passe, il fonctionne simplement de la même manière que pour les requêtes régulières.
Warning: session_write_close(): Failed to write session data (user)récemment reçu une erreur par intermittence dans un projet, mais uniquement lorsque la requête AJAX se produit pendant le chargement du reste de la page. J'utilise une base de données MySQL pour les données de session, et il est possible que la requête de la page principale verrouille cette table, empêchant la requête AJAX d'y accéder.
Si le fichier PHP des requêtes AJAX a un, session_start()les informations de session seront conservées. (à l'exception des demandes sont dans le même domaine)
Ce à quoi vous voulez vraiment en venir est: les cookies sont-ils envoyés avec la requête AJAX? En supposant que la requête AJAX concerne le même domaine (ou dans les limites de domaine du cookie), la réponse est oui. Ainsi, les requêtes AJAX vers le même serveur conservent les mêmes informations de session (en supposant que les scripts appelés émettent un session_start () comme pour tout autre script PHP souhaitant accéder aux informations de session).
Enfin, pas toujours. En utilisant des cookies, vous êtes bon. Mais le "puis-je compter en toute sécurité sur la présence de l'identifiant" m'a incité à prolonger la discussion avec un point important (surtout à titre de référence, car le nombre de visiteurs de cette page semble assez élevé).
PHP peut être configuré pour maintenir les sessions par réécriture d'URL, au lieu de cookies. ( Comment c'est bon ou mauvais (<- voir par exemple le commentaire le plus haut ici) est une question distincte , tenons-nous maintenant à la question actuelle, avec une seule note latérale: le problème le plus important avec les sessions basées sur l'URL - le flagrant visibilité de l'ID de session nu - ce n'est pas un problème avec les appels Ajax internes; mais ensuite, s'il est activé pour Ajax, il est également activé pour le reste du site, donc là ...)
En cas de sessions de réécriture d'URL (sans cookie), les appels Ajax doivent s'en occuper eux-mêmes - que leurs URL de requête soient correctement conçues. (Ou vous pouvez déployer votre propre solution personnalisée. Vous pouvez même recourir au maintien des sessions côté client , dans des cas moins exigeants.) Le point est le soin explicite nécessaire à la continuité de session, si vous n'utilisez pas de cookies:
Si les appels Ajax extraient simplement les URL textuellement du HTML (tel que reçu de PHP), cela devrait être OK, car elles sont déjà cuites (umm, cookifiées).
S'ils ont besoin d' assembler eux-mêmes les URI de demande, l'ID de session doit être ajouté manuellement à l'URL. (Vérifiez ici , ou les sources de page générées par PHP ( avec la réécriture d'URL activée ) pour voir comment le faire.)
De OWASP.org :
En effet, l'application web peut utiliser les deux mécanismes, cookies ou paramètres d'URL, voire basculer de l'un à l'autre (réécriture d'URL automatique) si certaines conditions sont remplies (par exemple, l'existence de clients web sans support de cookies ou lorsque les cookies ne sont pas accepté en raison de problèmes de confidentialité de l'utilisateur).
De message du forum Ruby :
Lors de l'utilisation de php avec des cookies, l'ID de session sera automatiquement envoyé dans les en-têtes de requête, même pour Ajax XMLHttpRequests. Si vous utilisez ou autorisez des sessions php basées sur des URL, vous devrez ajouter l'ID de session à chaque URL de requête Ajax.
Il est très important que les requêtes AJAX conservent la session. L'exemple le plus simple est lorsque vous essayez de faire une requête AJAX pour le panneau d'administration, disons. Bien sûr, vous protégerez la page à laquelle vous faites la demande, pour qu'elle ne soit pas accessible par d'autres personnes qui n'ont pas la session que vous obtenez après la connexion de l'administrateur. Logique?
Une chose à surveiller cependant, en particulier si vous utilisez un framework, est de vérifier si l'application régénère les identifiants de session entre les demandes - tout ce qui dépend explicitement de l'identifiant de session rencontrera des problèmes, bien que le reste des données dans la session ne sera pas affectée.
Si l'application régénère des identifiants de session comme celui-ci, vous pouvez vous retrouver avec une situation dans laquelle une demande ajax invalide / remplace en fait l'identifiant de session dans la page de demande.
C'est ce que font les frameworks, par exemple si vous initialisez la session dans Front Controller ou dans un script boostrap, vous n'aurez pas à vous soucier de son initialisation, ni pour les contrôleurs de page ni pour les contrôleurs ajax. Les frameworks PHP ne sont pas une panacée, mais ils font tellement de choses utiles comme ça!
mettez votre session () auth dans toutes les pages côté serveur acceptant une requête ajax:
if(require_once("auth.php")) {
//run json code
}
// do nothing otherwisec'est à peu près la seule façon dont je l'ai fait.
HttpOnlyindicateur lors de la configuration d'un cookie, ce qui signifie que votre Javascript ne pourra pas voir le cookie. Cependant, le cookie sera toujours envoyé pour les demandes de page AJAX et régulières et continuera à fonctionner exactement de la même manière. Votre Javascript ne le verra tout simplement pasdocument.cookie.