Impossible de modifier le nom du cookie de session php.

Question

J'ai copié un site existant et en cours d'exécution vers un nouveau serveur de développement.

La connexion sur le nouveau serveur est maintenant brisé, et je a dépisté au fait que même si le cookie de session est renommé ...

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

... le navigateur conserve le stockage du cookie sesssion comme PHPSESSID.

Lorsque je supprime la ligne ci-dessus de l'application sur le nouveau serveur, la connexion fonctionne à nouveau. Mais ce n'est pas une bonne solution, car une autre application utilise aussi PHPSESSID sous ce nom.

Et je préférerais trouver la raison du comportement étrange au lieu d'utiliser une solution de contournement. Si je ne le répare pas, ça pourrait me mordre ailleurs.

Peut-être que c'est déjà suffisamment d'informations pour que quelqu'un me donne un indice. Si non, quelle information serait utile?

Cette machine était un serveur ubuntu 8.04 très nu et basique, et j'ai installé apache2, mysql et php5 avec aptitude. J'ai également mis à jour lokales et le fuseau horaire.

Solution:

Je remplace la ligne ci-dessus avec ce code de de la réponse acceptée ...

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

... et la connexion fonctionne désormais sur le nouveau serveur.

Answer 1

Parfois ini_set joue et est incapable de définir les valeurs ini correctement, peut-être à des autorisations. Ce qui suit ne résout pas complètement le problème avec ini_set, et si quelqu'un connaît la (les) raison (s) pour laquelle ini_set ne fonctionne pas sur certains types d'hôtes, alors partagez!

Effectuez les opérations suivantes:

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

phpinfo(); 
?> 

Sinon, vous pouvez simplement utiliser session_name() pour le définir, et mal vous conseiller toujours de ne pas simplement d'exécuter les fonctions et nous espérons le vérifier toujours dans une instruction if et préparer au pire scénario, c'est quand votre application devient fiable et moins error_prone.