PHP: règles de pouce pour les sessions

Question

J'ai dû casser mon projet trop complexe, environ 100files, en petits fichiers. Un problème est qu'il est encore difficile de voir la logique, obtenir tas bien des erreurs de session:

`Cannot send session cookie - headers already sent by` 

Comment gérez-vous vos commandes de session, telles que « session de démarrage » et « ob-end chasse » ? Les ajoutez-vous au début et à la fin de votre index.php ou avez-vous un fichier centralisé pour les gérer?

Veuillez avoir une règle de pouce par réponse.

Answer 1

Cela pourrait ne pas être ce que vous demandez, mais aussi un petit indice:

Je laisse toujours la balise ouverte comme <?php ceci:

<?php 
class foo { 
    //... 
} 

//EOF 

De cette façon, vous ne pouvez pas avoir de sauts de ligne (sortie involontaire avant le début de la session) après le ?>, ce qui serait très difficile à trouver.

Cette convention est également utilisée par Zend Framework.

Answer 2

Peut-être pourriez-vous simplement utiliser le démarrage automatique de session pour vous assurer que la session est démarrée avant toute sortie?

http://us.php.net/manual/en/session.configuration.php#ini.session.auto-start

Answer 3

Tout ce que l'erreur signifie généralement est que vous avez quelque chose déjà sortie. La façon dont j'ai toujours contourné cela consistait à utiliser un moteur de template pour m'aider à ne penser à envoyer la sortie qu'à un seul endroit, une fois que j'ai fini de faire tout le reste. J'ai utilisé smarty, mais il y en a plein d'autres.

Answer 4

• Utilisez une sorte d'objet de réponse à regrouper vos données/en-têtes.

  Cela vous permet d'être sûr que vous pouvez envoyer tous les en-têtes simultanément et démarrer des sessions uniquement en cas de besoin, etc.

  Pros

  • Simplifie la gestion des réponses.
  • Permet d'agréger le contenu, et d'envoyer une sortie différente si une exception est levée, puisque le client n'a pas encore reçu de données

  Contre

  • Vous ne serez pas en mesure d'envoyer morceaux de données au client le plus tôt possible

Answer 5

je les mets en général au début/à la fin de index.php, puis incluez() les pages de contenu. Cela semble être une solution robuste car vous pouvez garantir que votre session est démarrée et sera nettoyée après le contenu.

Answer 6

Si vous voulez que votre projet soit logiquement bien organisé, la gestion de session n'a pas besoin d'être au début du code. En fait, si votre code est bien organisé, vous pouvez même le mettre presque au fin du processus, si vous ne voulez pas faire écho à un type de chaîne avant.

Personnellement, je préfère traiter les sessions et ob comme différentes bibliothèques (créées par moi-même en PHP pour être manipulées à ma façon), et je pense que c'est la meilleure solution. Mais cela dépend de ce que vous voulez réaliser.

Answer 7

Vous devez utiliser session_start() avant tout code qui produit des résultats (y compris, mais sans s'y limiter, l'envoi d'en-têtes, de cookies) afin que la section supérieure du premier fichier exécuté pendant un pageload soit un endroit sûr .

Answer 8

Vous pouvez utiliser un custom session handler implémenté comme singleton qui appelle session_start lors de sa création initiale. Toute autre opération de session est ensuite effectuée sur cet objet de session.

Le problème de contrôle de sortie peut être résolu en appelant ob_start au début de votre script d'index. L'appel ob_end_flush n'est pas nécessaire car le tampon de sortie est vidé automatiquement à la fin de l'exécution du script.