Posez votre question Format imprimable Liste des forums Aidez-les Statistiques Rechercher Charte Forum Webmastering

[PHP multi sessions]

Dernière réponse le 18 mar 2009 à 15:32:09 Walid, le 8 jun 2006 à 22:55:32

Signaler ce message aux modérateurs

Bonjour à tous,

Je développe un site où j'utilise les sessions (session_start()) afin d'authentifier les personnes qui s'y connectent et de gérer des variables de session.

J'étais content de découvrir que quand on ouvre un 2ème navigateur et qu'on pointe de nouveau vers une page où nous sommes déjà authentifié, la session ne se propage pas à la 2ème fenêtre.

Par contre si on fait un clic droit sur n'importe quel lien de la première fenêtre où on est authentifié et qu'on fait "ouvrir dans une nouvelle fenêtre") la session se propage à cette 2ème fenêtre.

Y a t il moyen d'éviter celà?

Merci.

Meilleures réponses pour « [PHP multi sessions] » dans :

Pach multi session msn 7.5 ?? (Résolu) Voir

Graver un DvD en multi session ? Voir

PHP ouverture session + identification (Résolu) Voir

[PHP] Headers already sent by..... VoirLorsque vous utilisez une fonction PHP qui manipule les en-têtes HTTP comme par exemple: header() setcookie() session_start() Il est important d'utiliser ces fonctions avant d'avoir généré le moindre flux vers le client. A partir du moment où...

Ouvrir plusieurs sessions simultanément sous MSN/WLM VoirPar défaut, il n'est possible d'ouvrir qu'une seule session à la fois sous MSN Messenger ou Windows Live Messenger. Cependant, il est possible de modifier ce comportement et permettre ainsi l'ouverture et la connexion de plusieurs sessions en...

MSN patch multi session wlm 9 Voir

Multi-session msn 7.5 Voir

Problème de gravure en multi-session Voir

Télécharger Alcohol 52% Free Edition Voir

PHP - Les variables d'environnement VoirNotion de variable d'environnement Les variables d'environnement sont, comme leur nom l'indique, des données stockées dans des variables permettant au programme d'avoir des informations sur son environnement. L'environnement, dans le cas du script...

Posez votre question Répondre

fgallnii, le 21 fév 2007 à 15:24:57

Je rencontre le "même problème" actuellement...

As tu trouvé une parade depuis ?? (même si le post date...)

Merci.

Répondre à fgallnii

Reivax962, le 21 fév 2007 à 16:47:14

Bonjour,

Les sessions sont gérées, entre autre, par le navigateur via un cookie de session. C'est donc lui qui "décide" comment faire, et on n'y peut rien.
Par exemple, avec Opéra, vous n'auriez pas ce problème... Mais Firefox et IE gèrent les sessions de façon globale (sauf ouverture d'un nouveau profil sous firefox).
Ce qui est sûr, c'est que du côté du webmestre, il n'y a pas de solution sans détruire la session précédente...

Xavier

Répondre à Reivax962

fgallnii, le 21 fév 2007 à 19:04:42

Ok merci pour ces infos :-)

Alors du coup, j'ai une autre petite question qui ma foi n'est plus tellement en accord avec ce sujet... mais bon...

J'ai entrepris de vouloir sérialiser un objet PHP5 afin de le passer en paramètre à la fenêtre que l'on souhaite ouvrir...
Jusque là j'étais content puisque ca marchait (même si c'étais pas très propre) seulement lorsque mon objet "prends du poids" (voir beaucoup de poids) et bien j'atteins la limite de la taille d'une url (j'récupère d'Apache, une erreur de type : Request-URI Too Large...)

Ma question est donc la suivante : ya t-il moyen de configurer Apache pour forcer la taille max d'une requete Url ?? j'ai chercher avec notre ami Google mais je ne trouve que la cause de cette erreur et en aucun cas de quoi la contourner ; alors est-ce possible ou non ? j'en sais toujours rien ! (sniff)

Pour ceux qui serait à cheval sur la sécurité, je tiens à préciser qu'aucune information personnelle ou confidentielle n'est concernée par l'objet sérialisé...

Sinon j'envisage de passer par un fichier texte mais là ca me gave car dans un environnement multi-utilisateurs c'est loin d'etre tip-top...

Merci d'avance pour vos réponses :-) ou pour toute autre suggestion

Répondre à fgallnii

Reivax962, le 21 fév 2007 à 19:13:36

Alors, deux solutions à mon avis.

1 - Il me semble bien avoir vu ça quelque part, en effet. Fouille ton httpd.conf, si tu lis l'anglais c'est bien commenté et tu derais pouvoir trouver rapidement la ligne qui va bien.

2 - Plus propre, à mon avis, ce serait de faire passer ton objet en POST plutôt qu'en GET. La taille admissible est plus grande.

Répondre à Reivax962

fgallnii, le 21 fév 2007 à 20:08:36

Merci pour ta réactivité Reivax962 !!!!

Bon, pour la première solution j'vais fouiner du côté de httpd.conf...

Sinon pour la deuxième solution, elle était venue à mon esprit... mais (parce qu'il y a souvent un "mais") est-ce qu'on peut appeler une image générée par PHP avec un POST ??

Je m'explique : ma page de départ permet de paramétrer un rapport en vu de le représenter à la fois sous la forme d'un tableau Html mais aussi d'un histogramme dans une autre fenêtre.

Je souhaite que l'utilisateur puisse générer autant de rapports (donc autant de fenêtres) qu'il souhaite avec différents paramètrages pour chaque rapport. Ceci va lui offrir la possibilité de comparer ces différents rapports visuellement à l'écran ou à l'impression.

Pour chaque fenêtre ouverte, j'ai une "moulinette technique" (pour passer les détails...) qui récupère les données du POST, puis qui à partir de celles-ci, les interprète sous la forme d'un tableau et d'une image (histogramme) appelée avec la balise <img src='./monImageQuePHPgenere.php'/>

Le fichier "monImageQuePHPgenere.php" lui se sert du tableau résumant les valeurs ; or pour des raisons de performances, je souhaite qu'il n'ai pas à refaire le même traitement qu'il a fallu pour le tableau. Donc en fait, une fois le tableau généré dans ma nouvelle fenêtre je souhaite le passer sous la forme d'un objet auprès du fichier :
monImageQuePHPgenere.php

Alors comment peut-on faire un appel avec des données en POST à une balise image dont la source est un fichier PHP ?? Avec la méthode visant à les passer en GET je fait un :

<img src='monImageQuePHPgenere.php?objetTableau=données_sérialisées'/>

Héhé pas évident et encore moins évident que vous compreniez mon ptit charabia... pas facile d'être concis pour ce besion... :s

Répondre à fgallnii

Reivax962, le 21 fév 2007 à 20:30:34

Ah, oui, je vois le problème...
Dans ce cas, je te conseille d'utiliser une session.

Une fois ton calcul fait, tu passes ton tableau en $_SESSION.
Ainsi, en ouvrant l'image, tu pourras le récupérer sans même qu'il n'ait dû passer par le réseau (gain de temps, en plus du reste !)

Répondre à Reivax962

fgallnii, le 21 fév 2007 à 21:25:27

Une fois de plus au taquet... chapot bas cher Reivax962 !!

L'idée des sessions elle la première que j'ai testée. Seulement, j'obtiens un comportement bizarre, puisque d'une fenêtre à l'autre un coups l'objet est retenu en session l'autre pas. Va savoir pourquoi ?!!?

Je pense que c peut-être à cause des différentes fenêtres externes qui pour pouvoir être multiples, ont toutes un nom de cible différent donc peut-être que ma session est valable que pour ma fenêtre de départ (elle où on paramètre les rapports désirés).

Comment ca un nom de cible ?? Eh bien, mon formulaire de départ ne peut pas ouvrir de multiples fenêtres avec une target "blank". Jusque là on est d'accord je pense, donc à la soumission du formulaire de départ, j'appelle une fonction JS qui construit un nom de fenêtre unique, puis qui l'attribut au target du formulaire et le soumet : ce qui ouvre une fenêtre différente avec les données postées afin d'obtenir tableau + graph. Cela me permet d'avoir mes multiples fenêtres.

C'est ça qui je pense fout la pagaille dans ma session. Comme si la session se mélanger les pinceaux d'une fenêtre à l'autre (or théoriquement ca devrait être la même).

Je sais pas ce que t'en penses Reivax962 ?? (pour bien faire faudrait que je me motives à faire un schéma... j'avoue qu'à cette heure j'ai un peu la flemme)

Répondre à fgallnii

fgallnii, le 22 fév 2007 à 12:03:00

Je viens de fouiller dans le httpd.conf pour trouver une éventuelle directive qui permet de régler le problème du URI-REQUEST TOO LARGE.
Rien de chez rien !! (snifff)

Par contre, j 'ai fouillé d'avantage sur Google et j'ai trouvé comment le faire. En fait, il faut modifier les binaires d'Apache puis refaire un make !

Cela pourrait marcher mais je pense que ca ne ferai que repousser le problème puisque si je met une nouvelle limite, peut-être que dans 6 mois elle sera atteinte donc de nouveau je serai embêté...

Conclusion : j'suis toujours bloqué !! d'autant plus que j'ai cherché pour passer le POST sur une image PHP : impossible !! et j'ai toujours ma session d'une fenêtre à l'autre qui merdouille !! peut-être que la mise en place d'un sémaphore me sortirai de cette m.... !!

Répondre à fgallnii

Reivax962, le 22 fév 2007 à 12:09:59

Bon, si les sessions ne passent pas, dernière solution : mets tout ça dans un cookie.

Répondre à Reivax962

fgallnii, le 22 fév 2007 à 12:31:17

Hoho bien vu !!!! complètement zappé !

Ah voui là ya des chances que ca passe !!
Je te retiens au courant dans l'aprem !

Merci à toi Reivax962 :)

Répondre à fgallnii

fgallnii, le 22 fév 2007 à 14:11:28

Bon je viens tester avec les cookies ! ca marche à merveille héhé !!

MAIS ya encore un problème... lol beh c'est que j'atteinds très vite la taille maximale d'un cookie (4Ko) une fois mon objet sérialisé. Pas de peau !

J'crois que la solution finale va être d'effectuer deux fois le traitement tanpis pour les performances. J'avoue que ca m'embete quand même beaucoup puisque d'un traitement d'environ 7secondes ca me fait passer à un traitement de 14secondes !!! c'est quand même pas négligeable (et ça, c'est seulement pour 6 mois de données donc j'vous laisse imaginer pour un rapport sur une année...)

Je laisse le sujet ouvert si toutefois vous avez encore des idées...

Répondre à fgallnii

Reivax962, le 22 fév 2007 à 14:23:48

Argh...
Bon, alors, dernière idée : simuler les sessions :p
Prérequis : il faudrait que tu aies quelque chose pour identifier de façon unique une session. Tu dois pouvoir utiliser session_id(), mais ça peut aussi être un login ou autre. Appelons cet identificateur ID.

Lors de ton premier traitement, tu mets l'objet sérialisé dans un fichier sur ton serveur, avec ID comme nom de fichier.

Lorsque tu veux générer l'image, tu lis le fichier correspondant à ID, le désérialises, et tu en fais ce que tu veux.
Après, tu peux supprimer le fichier en question pour éviter que cela prenne trop de place.

Répondre à Reivax962

virtualsof, le 18 mar 2009 à 15:32:09

Bonjour,

Super, mais comment est-ce qu'on fait ca svp ?

Merki

Répondre à virtualsof

fgallnii, le 22 fév 2007 à 14:30:15

Encore une bonne idée !!

Ouhaip beh j'vais tenter cette tit'technique, mais c'est clair qu'il n'y a pas de raison que ca ne passe pas...

J'envisage de faire un fichier unique temporaire pour le coups. Sais-tu quand est-ce que PHP fais le ménage des fichiers temporaires ?? (Comme ca je n'ai pas à le faire, et j'évite les chances d'écrasements de données dans le cas où l'utilisateur demande 'n' rapports au même instant 't')

Répondre à fgallnii

Reivax962, le 22 fév 2007 à 14:34:43

Aucune idée, je ne savais pas que php savait gérer des fichiers temporaires ^^'

Sinon, pour le problème du nom de fichier, tu peux générer une chaine de 16 ou 32 caractères au hasard, et ne passer que celle-ci en session pour avoir un ID unique sur chaque fichier, même si l'utilisateur lance 5 calculs en même temps.

Répondre à Reivax962

fgallnii, le 22 fév 2007 à 14:41:32

Ouhaip c'est une bonne idée aussi pour la chaine de caractères aléatoire.

Sinon je me suis renseigné pour les fichiers temporaires... ils se font à l'aide de la fonction tmpfile() dès lors tu peux écrire, lire dedans à volonté et dès que tu les fermes avec "fclose()" PHP fait le ménage de suite...

J'explore cette voie, et te tiens informé,

Encore Merci :)

Répondre à fgallnii

fgallnii, le 22 fév 2007 à 14:57:32

ME REVOILA !!! héhé !!! et ce coups ci, ya que du bon !!!

Alors alors par où je commence ??
Bon beh j'ai suivi une fois de plus tes conseils Reivax962 à un ptit détail près, je m'explique :

Vu que j'ouvre chaque fenêtre avec un identifiant unique et bien je crée un fichier par fenêtre pour stocker les données puis après lecture pour le graphique je le supprime aussitôt. De ce fait, aucune chance qu'il soit écrasé ou qu'une autre fenêtre vienne écrire ou lire dedans.
J'ai actualisé plusieurs fois chaque fenêtre, elles recréent toute un fichier puis le supprime avant affichage, donc c'est formidable.

Quand je vois aujourd'hui où on en ai arrivé pour cette tit'bidouille (beh voui parce que faut être honnête c'est pas ce qu'il ya de plus propre mais au moins ca marche) eh bien je dis un grand merci à Reivax962 !!!

Où est-ce qu'on peut voter pour Reivax962 ?!!??? hein ? parce que là ca vaut un +10 à tout point de vue (réactivité, pertinence, ...)

Je reviendrai clore le sujet dans la journée, si toutefois d'autres idées arrivent.

Encore merci Reivax962 !! :)

Répondre à fgallnii

Reivax962, le 22 fév 2007 à 15:00:59

Youpi, on y est arrivé :)
Bien joué :)

Répondre à Reivax962

fgallnii, le 23 fév 2007 à 16:51:48

Yip yop !

Tit'question comment est-ce qu'on marque le sujet comme résolu ?? :s

Merki ;)

Répondre à fgallnii

LaNceLoT, le 11 oct 2007 à 19:51:09

En passant par une base de donnée ça aurait aussi marcher ^^

-LaNceLoT-

Répondre à LaNceLoT

silfaxu, le 6 fév 2008 à 16:40:52

Salut,

Ok le sujet est pas récent :-) mais bon pour le problème suivant :
"Je viens de fouiller dans le httpd.conf pour trouver une éventuelle directive qui permet de régler le problème du URI-REQUEST TOO LARGE.
Rien de chez rien !! (snifff) ", il faut peut-être jeter un coup d'oeil du côté de la directive :
LimitRequestBody Directive
This directive specifies the number of bytes from 0 (meaning unlimited) to 2147483647 (2GB) that are allowed in a request body.
cf: http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody

@+

Sfx

Répondre à silfaxu

fgallnii, le 6 fév 2008 à 16:57:23

Salut,

Ca a l'air plutôt intéressant et c'est vrai que je n'avais pas vu ce détail de conf.
Je ne suis plus dans le même contexte qu'à l'époque et malheureusement je ne vais pas pouvoir tester...

Merci en tout cas pour ta contribution !

@pluche :-)

Répondre à fgallnii

Posez votre question Répondre