Kann nicht ändern, PHP Session-Cookie-Name

Question

Ich kopierte eine bestehende und erfolgreich ausgeführte Website auf einen neuen Entwicklungsserver.

Die Anmeldung auf dem neuen Server ist nun gebrochen, und ich verfolgte sie auf die Tatsache, dass, obwohl die Session-Cookie wird umbenannt ...

ini_set('session.name', 'DOMAIN1'); 

... hält der Browser die sesssion Cookie gespeichert als PHPSESSID.

Wenn ich die obige Zeile aus der Anwendung auf dem neuen Server entfernen, funktioniert die Anmeldung erneut. Aber das ist keine gute Lösung, weil eine andere Anwendung auch PHPSESSID unter diesem Namen verwendet.

Und ich würde lieber den Grund für das seltsame Verhalten finden, anstatt einen Workaround zu verwenden. Wenn ich es nicht repariere, könnte es mich woanders hinbeißen.

Vielleicht ist dies bereits genug Informationen für jemanden, der mir einen Hinweis gibt. Wenn nicht, welche Informationen wären nützlich?

Diese Maschine war ein sehr nackter und einfacher Ubuntu 8.04 Server, und ich installierte apache2, mysql und php5 mit aptitude. Ich aktualisierte auch Lokales und die Zeitzone.

Lösung:

ersetzt ich die Linie oben mit diesem Code aus der akzeptierten Antwort ...

if(ini_set('session.name', 'DOMAIN1') === false || !session_name('DOMAIN1')) 
{ 
    die('Unable to set sesssion scope'); 
} 

... und die Login funktioniert jetzt auch auf den neuen Server.

Answer 1

Manchmal ini_set spielt auf und ist nicht in der Lage, die Ini-Werte korrekt festzulegen, möglicherweise auf Berechtigungen.

das unten löst nicht vollständig das Problem mit ini_set, und wenn jemand die Gründe kennt, warum ini_set funktioniert nicht auf einige Arten von Host, dann bitte teilen!

Versuchen Sie Folgendes:

<? 
if(ini_set('session.name', 'DOMAIN1') === false || !session_name('DOMAIN1')) 
{ 
    die('Unable to set sesssion scope'); 
} 

phpinfo(); 
?> 

alternativ können Sie nur session_name() verwenden es zu setzen, und krank immer beraten Sie nicht auf Funktionen nur laufen und hoffen, dass die immer die if-Anweisung in ein überprüfen und auf das Schlimmste vorbereiten Case-Szenario, das ist, wenn Ihre Anwendung zuverlässig und weniger error_prone wird.