Sessions sind eine prima Sache, wer Daten über mehrere Scripte hinaus austauschen will, der greift darauf zurück.
Leider passiert es nun manchmal, dass man ein eigenes Script als fertiges HTML benötigt – ein include() per HTTP fällt aber auf vielen Servern dank der allow_url_include Konfigurationseinstellung flach, also muss cURL her.
Mit cURL können wir ein beliebiges Script per HTTP aufrufen und den Inhalt in der aktuellen Seite einbinden, ohne dass ein User etwas davon merkt.

Wer nun aber denkt, er könne die Session-Daten auch in dem Script abgreifen, das per cURL geladen wird, der wird sein blaues Wunder erleben. cURL generiert jedesmal eine neue Session-ID, anstatt die vorhandene fortzusetzen – ist ja auch klar, das ist, als ob man einen zweiten Browser startet, also übergibt man die Session-ID. Entweder kann man diese einfach als GET-Parameter anhängen, oder man setzt eine cURL-Option für ein Cookie.

Das sieht dann so aus:

Wer jetzt das Script aufruft, wird mit einer Sanduhr belohnt. Das Script läd und läd und hört nicht auf. Ein neuer Seitenaufruf schlägt ebenfalls fehlt und wird wieder mit einer Sanduhr belohnt. Der User denkt dann sein Browser wäre abgestürzt, weil nichts mehr funktioniert.

Warum?

Wenn man es weiß, ich die Lösung (wie immer) ganz einfach.
PHP schreibt die Session-Daten erst bei der Beendigung eines Scripts in die Datei auf dem Server. Während das Script läuft, ist die Datei gesperrt, so dass nicht mehrere Scripte gleichzeitig die Daten ändern. Wir müssen also dafür sorgen, dass die Session-Daten gespeichert werden, bevor wir das nächste Script aufrufen. Das erledigt session_write_close(); für uns.

Die Daten in der Superglobalen $_SESSION stehen nach dem Schließen selbstverständlich noch (read-only) zur Verfügung.
Lese- und Schreibrechte hat jetzt aber das per cURL aufgerufene Script.