Wenn sich ein Benutzer auf meiner Website angemeldet und seine ID gespeichert $_SESSIONhat und er in seinem Browser auf die Schaltfläche "Speichern" geklickt hat, wird eine AJAX-Anfrage an den Server gesendet. Werden seine $_SESSIONund Cookies in dieser Anfrage beibehalten, und kann ich mich sicher darauf verlassen, dass die ID in der vorhanden ist $_SESSION?
Antworten:
Die Antwort ist ja:
Sitzungen werden serverseitig verwaltet. Für den Server gibt es keinen Unterschied zwischen einer AJAX-Anforderung und einer regulären Seitenanforderung. Sie sind beide HTTP-Anforderungen und enthalten auf die gleiche Weise Cookie-Informationen im Header.
Von der Clientseite werden immer dieselben Cookies an den Server gesendet, unabhängig davon, ob es sich um eine reguläre Anfrage oder eine AJAX-Anfrage handelt. Der Javascript-Code muss nichts Besonderes tun oder sich dessen bewusst sein, er funktioniert genauso wie bei regulären Anfragen.
Warning: session_write_close(): Failed to write session data (user)letzter Zeit gelegentlich einen Fehler in einem Projekt erhalten, aber nur, wenn die AJAX-Anforderung während des Ladens des Restes der Seite auftritt. Ich verwende eine MySQL-Datenbank für die Sitzungsdaten, und es ist möglich, dass die Hauptseitenanforderung diese Tabelle sperrt und verhindert, dass die AJAX-Anforderung darauf zugreift.
Wenn die PHP-Datei, die die AJAX-Anforderungen enthalten, eine enthält, werden session_start()die Sitzungsinformationen beibehalten. (Entblößen der Anfragen befinden sich innerhalb derselben Domain)
Was Sie wirklich verstehen, ist: Werden Cookies mit der AJAX-Anfrage gesendet? Angenommen, die AJAX-Anforderung bezieht sich auf dieselbe Domäne (oder innerhalb der Domänenbeschränkungen des Cookies), lautet die Antwort "Ja". AJAX-Anforderungen an denselben Server behalten also dieselben Sitzungsinformationen bei (vorausgesetzt, die aufgerufenen Skripts geben einen session_start () aus, wie bei jedem anderen PHP-Skript, das Zugriff auf Sitzungsinformationen wünscht).
Nun, nicht immer. Mit Cookies sind Sie gut. Aber das "Kann ich mich sicher darauf verlassen, dass die ID vorhanden ist" drängte mich, die Diskussion um einen wichtigen Punkt zu erweitern (hauptsächlich als Referenz, da die Besucherzahl dieser Seite ziemlich hoch zu sein scheint).
PHP kann so konfiguriert werden, dass Sitzungen durch Umschreiben von URLs anstelle von Cookies verwaltet werden. ( Wie es gut oder schlecht ist (<- siehe z. B. den obersten Kommentar dort), ist eine separate Frage . Lassen Sie uns nun mit nur einer Randnotiz bei der aktuellen bleiben: dem wichtigsten Problem bei URL-basierten Sitzungen - dem offensichtlichen Sichtbarkeit der nackten Sitzungs-ID - ist kein Problem bei internen Ajax-Aufrufen, aber wenn sie für Ajax aktiviert ist, ist sie auch für den Rest der Site aktiviert, also dort ...)
Bei Sitzungen zum Umschreiben von URLs (ohne Cookies) müssen Ajax-Aufrufe selbst dafür sorgen, dass ihre Anforderungs-URLs ordnungsgemäß erstellt werden. (Oder Sie können Ihre eigene benutzerdefinierte Lösung erstellen. In weniger anspruchsvollen Fällen können Sie sogar auf die Verwaltung von Sitzungen auf der Clientseite zurückgreifen .) Der Punkt ist die explizite Sorgfalt, die für die Kontinuität der Sitzung erforderlich ist, wenn keine Cookies verwendet werden:
Wenn die Ajax-Aufrufe nur wörtlich URLs aus dem HTML-Code extrahieren (wie von PHP empfangen), sollte dies in Ordnung sein, da sie bereits gekocht sind (umm, gekocht).
Wenn sie müssen Anforderungs-URIs selbst zusammenstellen müssen, muss die Sitzungs-ID manuell zur URL hinzugefügt werden. (Überprüfen Sie hier oder die von PHP generierten Seitenquellen ( mit aktivierter URL-Umschreibung ), um zu sehen, wie es geht.)
Von OWASP.org :
Tatsächlich kann die Webanwendung beide Mechanismen, Cookies oder URL-Parameter verwenden oder sogar von einem zum anderen wechseln (automatisches Umschreiben von URLs), wenn bestimmte Bedingungen erfüllt sind (z. B. das Vorhandensein von Webclients ohne Cookie-Unterstützung oder wenn Cookies dies nicht tun) aufgrund von Datenschutzbedenken des Benutzers akzeptiert).
Aus einem Ruby-Forum- Beitrag:
Bei Verwendung von PHP mit Cookies wird die Sitzungs-ID automatisch in den Anforderungsheadern gesendet, auch für Ajax XMLHttpRequests. Wenn Sie URL-basierte PHP-Sitzungen verwenden oder zulassen, müssen Sie die Sitzungs-ID zu jeder Ajax-Anforderungs-URL hinzufügen.
Es ist sehr wichtig, dass AJAX-Anforderungen die Sitzung beibehalten. Das einfachste Beispiel ist, wenn Sie versuchen, eine AJAX-Anfrage für das Admin-Panel zu stellen. Natürlich schützen Sie die Seite, auf die Sie die Anfrage stellen, und sind für andere, die nicht über die Sitzung verfügen, die Sie nach der Administratoranmeldung erhalten, nicht zugänglich. Macht Sinn?
Eine Sache, auf die Sie achten sollten, insbesondere wenn Sie ein Framework verwenden, ist zu überprüfen, ob die Anwendung Sitzungs-IDs zwischen Anforderungen neu generiert - alles, was explizit von der Sitzungs-ID abhängt, wird auf Probleme stoßen, obwohl offensichtlich der Rest der Daten in Die Sitzung bleibt davon unberührt.
Wenn die Anwendung Sitzungs-IDs wie diese neu generiert, kann es vorkommen, dass eine Ajax-Anforderung die Sitzungs-ID auf der anfordernden Seite ungültig macht / ersetzt.
Dies ist, was Frameworks tun, z. B. wenn Sie eine Sitzung in Front Controller oder Boostrap-Skript initialisieren, müssen Sie sich weder für Seiten-Controller noch für Ajax-Controller um die Initialisierung kümmern. PHP-Frameworks sind kein Allheilmittel, aber sie machen so viele nützliche Dinge wie diese!
Fügen Sie Ihre session () -Authentifizierung auf allen serverseitigen Seiten ein und akzeptieren Sie eine Ajax-Anfrage:
if(require_once("auth.php")) {
//run json code
}
// do nothing otherwiseDas ist ungefähr der einzige Weg, wie ich es jemals gemacht habe.
HttpOnlybeim Setzen eines Cookies ein Flag setzen, was bedeutet, dass Ihr Javascript das Cookie nicht sehen kann. Das Cookie wird jedoch weiterhin sowohl für AJAX- als auch für reguläre Seitenanforderungen gesendet und funktioniert weiterhin genauso. Ihr Javascript wird es einfach nicht sehendocument.cookie.