8
votes

Pourquoi les sessions Laravel n'échouent-elles pas simplement Safari et IE après la commutation de serveur?

Nouveau serveur VPS avec webmin, Apache Centos 6, Application Laravel et Old Base de données Schema. Tout allant bien sur l'ancien hôte partagé, mais sur VPS pour une raison quelconque, le stockage de la session de Laravel (Laravel 3.0) ne travaille plus sur Safari ou Internet Explorer.

Il semble que l'ID de session ne soit tout simplement pas enregistré sur le client. Est un bon moyen de forcer l'ID de la session de Laravel à économiser sur le navigateur des clients?

Quelles sont les différences entre les cookies de Safari / IE Store qui pourraient créer ce problème, lorsque Chrome / Firefox semble fonctionner parfaitement bien?


4 commentaires

J'ai ce problème exact avec la même configuration: Apache2.2, PHP 5.4.17, Laravel 4.0.x Tous fonctionnant sur Centos 6.4. Fonctionne bien sur Localhost, mais sur le serveur, c'est-à-dire et Safari n'accepte ni n'envoie aucun cookies de session. Ont été perplexes par tout cela tous les matins ...


Je suis plutôt bon au dépannage des cookies de session dans les navigateurs. Cette question m'a intriguée. Je n'ai jamais travaillé avec Laravel avant, mais je pouvais plus que probablement vous donner une réponse si je pouvais reproduire votre problème. Par défaut, Laravel utilise le pilote de session natif afin que ce ne soit pas difficile de dépanner. Envoyez-moi une procédure sur la façon de reproduire ou peut-être peut-être me donner un lien vers une page afin que je puisse voir comment il se comporte sur les différents navigateurs.


Hi Ray, je vais mettre en place des données supplémentaires pour vous, en particulier la sortie du réseau sur IE et Safari sur deux hôtes de test, supportez-moi.


Vous devez fournir plus d'informations sur votre problème. Si vous lisez la documentation de la session sur php.net, vous comprendrez qu'il y a beaucoup de choses qui peuvent se tromper avec des sessions dans PHP. Ce n'est peut-être même pas lié le cadre. Je vous suggère de désactiver le démarrage automatique et de vous familiariser avec Configuration de la session PHP , Définissez le nom de domaine, le nom de la session correctement, assurez-vous d'avoir un accès en écriture à votre dossier de stockage de session et surtout, assurez-vous que vos classes d'objet Sessions stockées sont chargées avant de commencer la session!


4 Réponses :


0
votes

Vous devez vérifier que tout sur le nouveau serveur est identique à l'ancien serveur ... une version plus ancienne ou plus récente de logiciel pourrait le faire, peut-être même des paramètres htacks différents ...
2 autres choses à considérer ...
Peut-être qu'un fichier a été corrompu pendant le mouvement ... Ou il y a quelque chose sur le serveur côté nettoyer les choses ... La société d'hébergement gratuite que j'ai utilisée avait des fenêtres contextuelles, et à cause de ces popups, vous ne pouvez pas utiliser de carte de site régulière pour l'indexation de Google, car les popups injectèrent quelque chose dans votre page. . de
Je viens aussi de trouver ceci ... session n'initialise pas ou rappelez-vous l'état entre les demandes p>

Ce que je ne savais pas, l'appel à Setcookie préfixera automatiquement le domaine avec une période (.) pour la compatibilité. Qui sur un niveau de racine Nom de domaine, il permettra à ce cookie d'être consulté sur tous sous-domaines. Qui, pas la réalisant cela, m'a donné 2 biscuits de session et un Big Mixup est arrivé. P>

Il semble y avoir 2 façons de résoudre ce problème: p>

Set the cookie configuration value to something else.

Set the domain to "www.example.org" so that it is only available to the root-level domain name.


0 commentaires

16
votes

Les cookies peuvent obtenir des culottes dans une torsion si l'heure / l'horaire du serveur n'est pas correcte. Vérifiez le réglage TimeZone / Date sur le serveur.

Notez que vous devez vérifier l'heure / le fuseau horaire réel dans le système d'exploitation, pas seulement le fuseau horaire dans PHP. Mais vous pouvez vérifier à l'aide de PHP en définissant le fuseau horaire dans PHP ( date_default_timezone_set () ) à votre heure locale et demandez à PHP pour la date; S'il ne correspond pas, le serveur est défini de manière incorrecte. Notez que l'ajustement du fuseau horaire dans PHP pour que le problème ne puisse pas corriger le problème de la cookie, vous devez définir correctement le temps de coquillage / la fuseau horaire à l'aide de «date» dans le système d'exploitation.

Une autre façon de vérifier si c'est le problème: définir un cookies expirer dans une année - Montrez-vous? Si le fuseau horaire est faux, ceux-ci montrent (> différence de fuseau horaire), mais un cookie de 2 heures peut ne pas (

Raison: comme les cookies sont définis à l'aide de l'heure actuelle (c'est-à-dire «Ce cookie expire le 25 juillet 2013 15:13 GMT»). Si votre ordinateur local est défini différemment du serveur, le cookie peut apparaître expiré avant son envoi. Certains navigateurs correctent pour cela (FF UTILISÉS, Chrome May May maintenant).

Comme la chose qui a changé ici est le serveur, vérifiez l'heure de votre serveur. (Vérifiez également votre propre ordinateur pour une bonne mesure).


3 commentaires

C'est en fait plus que probablement probablement le problème. Le serveur est sur un VM qui est assis dans un état de pause pendant des périodes prolongées de temps qui joue des ravages avec l'horloge ... Je vais essayer de le réinitialiser et voir si cela aide.


Sainte Moly. Merci beaucoup. Je me frappe la tête d'un mur de briques, je me demandais si j'avais quelque chose de mal dans ma configuration Laravel. Je ne pouvais pas y travailler - et c'était purement que mes tests IE9 à VirtualBox avaient la mauvaise installation de fuseau horaire et que, par conséquent, c'était en réalité à l'heure parfaite.


Cette réponse m'a enregistré des heures de recherche, j'ai une application d'enregistrement de temps avec une session expirant après 5 minutes et que l'heure du serveur était de 1 heure de retard ..



2
votes

Ceci est un problème classique de domaine croisé / iframe de Safari / Safari.

Correctif potentiel pour le problème de la cookie de Laravel, c'est-à-dire iframe (travaillé pour moi). Il suffit d'ajouter ceci à votre application :: Après filtre. xxx

Vous pouvez même préciser, pour quel itinéraire vous avez besoin de cet en-tête, pour moi, c'était tout au-delà / externe /, Donc, le code semble liek ceci: xxx


0 commentaires

1
votes

J'ai ce problème et je le résolvez comme ceci: mon .htaccess ne redirige pas exemple d'exemple à www.example.com et mon URL que je veux aller N'a pas de www mais j'étais login dans www.example.com .

au lieu de ceci: < / p> xxx

J'ai utilisé ceci: xxx

avec ce remplacement, vous continuerez avec n'importe quelle adresse que vous avez entrée. Avec ou sans "www"


0 commentaires