[PHP multi sessions]

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.

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

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

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

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

Merci.

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

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...

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')

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.

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 :)

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 !! :)

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

Yip yop !

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

Merki ;)

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

-LaNceLoT-

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

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 :-)

pour revenir sur ce problème de multisession...et en passant la viriable d'identification dans l'url, est-ceque ca ne résoud pas le problème N?

phenX attention il faut préciser qu'avec ta méthode n'importe qui peut quand tu es connecté durant ta connexion en plaçant à la fin de url la bonne variable il se retrouve directe sur ton compte mais ton idée et bonne j'ai commençé comme ça et je l'ai couplé à ce qui suit.

//voila ce que j'ai pondu dans mon super petit cerveau les ip sont la solution.car iP source ne change jamais normalement que du bonheur.
//et le multisession avec la méthode get ne pose plus de problème avec cette méthode on est tranquille en théorie et si ma théorie n'a pas de faille (l'espoir fait vivre;)).

$chaine=$_SERVER['REMOTE_ADDR'];
$varchar=$_SERVER['HTTP_USER_AGENT'];//garantie que l'utilisateur ne s'amuse pas à gérer deux fois la même session avec 2 navigateur différent à un même instant
$chaine=ereg_replace("[^0-9]","",$chaine);
$varchar=ereg_replace("[^aA-zZ]","",$varchar);
$chaine="superchichon".$varchar.$chaine;//dans mes test sans varchar fonctionne aussi bien mais théoriquement il est nécessaire donc je le laisse.
session_name($_SERVER['REMOTE_PORT']);//port change tout le temps et à l'instant ou il est générer il est unique et change tout le temps donc évite le cas ou 2 personne d'un même sous réseau on accés à un serveur en externe et donc même session id peu donner naissance à des soucies
session_id ("superchichon".$chaine.$_GET['user']);//.$_GET peut être utilisé mais je précise lire plus bas le ATTENTION.
session_start();

même si quelqu'un met en place sont propre serveur web avec sont propre formulaire pour initier les variable comme il se doit et générer une redirection sur votre serveur celle ci ne devrez pas aboutir d'après mes tests, de même avec quelqu'un qui piraterai votre point d'accès pour avoir votre ip il ne devrait pas aboutir j'ai essayer de trouver un truc simple et générique.
ATTENTION METHODE VALABLE a condition de checker à chaque clic les variable d'identification car si l'utilisateur s'amuse à changer son nom d'utilisateur dans l'url il passera d'un compte à un autre comme bon lui semble(quand la menace c'est votre camarade de travail mais ou s'arrête l'infamie et l'horreur de la suspicion).

Sous cette forme des personnes peuvent avoir accès à la même session sans se géner.
oiseaustyle vous lache une petite blague
une Hecker non je préfére un double décimétre blague à Vincentim que mes poto comprendrons

personnellement je n'utilise pas le $_GET[''] car trop de gens m'ont dit que le passage de valeur en get pour l'authentification était trop aisément piratable, j'utilise donc cette méthode sans $_GET donc en monosession.
donc plusieur personne ont accés à des comptes sans ce géner et même au même compte pour ceux qui partage leur compte sur les webinterfaces que j'ai bidouiller mais une personne ne peut sur un poste avoir accès qu'à un compte elle doit le fermer ou utiliser un deuxième navigateur genre firefox et opera pour avoir deux compte d'ouvert en même temps.

si quelqu'un test ce que j'ai pondu en multisession j'aimerais bien avoir des échos je repasserai à l'occasion.
chao