Discussion :

[manuscle]

Bonjour à tous!

Je rencontre un problème pour avoir une session différente par onglet, j'explique:

A la fin du script php j'enregistre l'url complète en session, ce qui me permet sur la requete qui suit de savoir ou l'utilisateur se trouvait avant. Si je doit faire un retour arrière, je n'ai plus qu'a appeler cette url et de rediriger vers celle-ci avec php.

ça marche nickel sauf lorsque l'utilisateur navigue par onglet.... si il change d'url dans l'onglet 1 et que ensuite il fait une action dans l'onglet 2, php le renvoie vers l'url enregistrée via l'onglet 1.... Donc tout mon système est foutu

Je ne sais pas comment faire autrement! Y a bien la soution d'indiquer l'url en parametre dans la requete mais je trouve ça moche et ça fait des urls à rallonge....

Avez-vous une astuce?

[RunCodePhp]

C'est justement le fait d'enregistrer l'URL dans la session qui cause problème.
Normalement il n'y pas lieu de faire ainsi.

Pourquoi ne pas mettre l'url de page précédente, la vrai page ?

Les cas où il semble utile de savoir dans quelle page l'utilisateur se trouvait, c'est lorsqu'il tente d'afficher une page qui demande une identification.
Là, on enregistre la page où il se trouvait, il s'identifie et hop, on le redirige là où il souhaitait aller.
Sinon, le plus souvent on sait quelle est la page précédente non ?

[manuscle]

C'est justement le fait d'enregitrer l'URL dans la session qui cause problème.
Normalement il n'y pas lieu de faire ainsi.

Comment fait-on alors?

[RunCodePhp]

Comment fait-on alors?

En mettant le nom de la page tout simplement.
Si la personne se trouve dans la rubrique 2, et bien on mets un lien vers la rubrique 1, par exemple.
Il n'est utile ici d'enregistrer quoi que ce soit en session, non ?


Mais c'est à toi d'expliquer comment tu effectue les choses, et peut être qu'on verra un problème.

[manuscle]

Oui tu as raison il faut que j'explique un minimum, mais ceci n'est pas chose simple!
Déjà, je suis dans une architecture mvc (Zend Framework).... juste pour info. Mais ceci concerne plus une pratique générale que du ZF en particulier.

Bon je me lance:

J'ai un catalogue en ligne qui affiche des articles, j'ai deux pages bien distinctes:
- la liste des articles avec des parametres de filtre d'affichage(page, nom etc...) dans l'url ex. 'http://monsite.com/article/liste?page=1&order=title&way=asc'
- la fiche article 'http://monsite.com/article/fiche?article=1'

Dans la liste d'articles j'ai pour chaque article:
- un lien 'voir' me permettant d'aller sur la fiche
- un lien 'editer' me permettant d'aller vers la page d'édition de l'article

Dans la fiche article, j'ai :
- un lien 'editer' me permettant d'aller vers la page d'édition de l'article
- un lien 'retour' me permettant de retourner d'ou je viens

Dans la page d'édition de l'article je souhaite générer une url de 'retour' qui doit refrabriquer l'url d'où je viens au post du formulaire ou si l'utilisateur clique sur retour, je dois donc être en mesure de savoir où est-ce que je me trouvais précédement (dans la liste ou dans la fiche) et quels étaient les parametres.

Je pense que la seule solution est de renvoyer les parametres dans l'url et d'ajouter des parametres genre je suis en edition et j'arrive de la liste, l'url serait
'/article/editer?article=1&page=1&order=title&way=asc&oldAction=liste'

Mais ceci est fastidieux car si un jour je décide d'ajouter un parametre dans liste ou que j'arrive d'ailleur dans l'édition, je doit surveiller que tout ceci ne va pas interférer lorsque j'arrive sur la page d'édition.

Si tu as mal au crane j'ai de l'aspirine dans mon bureau! Je suis vraiment désolé si c'est difficile à comprendre, j'ai moi même du mal à expliquer.

[RunCodePhp]

Dans la page d'édition de l'article je souhaite générer une url de 'retour' qui doit refrabriquer l'url d'où je viens au post du formulaire ou si l'utilisateur clique sur retour, je dois donc être en mesure de savoir où est-ce que je me trouvais précédement (dans la liste ou dans la fiche) et quels étaient les parametres.

Avec le HTTP_REFERER, ça devrait être possible normalement, non ?

C'est vrai qu'il y a des cas particuliers, j'en ai même donné un qui justement pourra difficilement ce faire sans les sessions, mais il faut reconnaitre aussi que naviguer entre 2 fenêtres ou onglets en parallèle n'est pas une navigation tout a fait normal.
Faut voir si le problème vaut le coup d'être traiter.
C'est un peu comme si ton utilisateur supprimait ses cookies d'un coup comme ça, et qu'il te dis que c'est anormal qu'il se déconnecte.
Faut il traiter le cas ?


Je reconnais que là, ça risque d'être un peu compliqué de contrer ce phénomène.
Le plus simple, ça ne va pas te satisfaire à mon avis, mais c'est de ne pas proposer de lien en retour, en tout cas, pas avec ton principe.
La personne peu retourner là où elle était avec le retour du navigateur.
Justement, tu pourrais exploiter Javascript, et l'historique (back - 1).

Sinon, peut être faudrait il vérifier vers où le retour pointe, et le créer que si c'est une page semble correcte.

Enfin, je te donne ce qui me viens à l'esprit.
ZF, c'est au-dessus de mes connaissances déjà.

[manuscle]

HTTP_REFERER je peux pas lui faire confiance car certains navigateurs l'exploitent à d'autres fins, ou même ne l'exploite pas du tout.... c'est bien dommage.

En fait dans ma boite j'ai encouragé les utilisateurs admin à avoir deux onglets, un sur l'admin du site et un sur la partie publique, c'est très pratique dans ceratins cas ...... j'aurais du me taire encore une fois
Du coup les utilisateurs me disent que lorsque ils sont en admin sur l'onglet 1 et qu'ils valident un truc, lorsqu'ils vont sur l'onglet 2 et qu'ils effectuent une action, le retour se fait sur la page de l'onglet 1.....

Sinon j'avais eu l'idée de mettre en place un système de tableau dynamique de navigation qui enregistre automatiquement l'url avec un id genre timestamps unix par exemple. Lorsque je crée mes url j'envoie en parametre l'id qui permettra lors de la génération des liens 'retour' d'aller chercher l'url correspondante....

Merci quand même pour ton aide

Si quelqu'un a une idée ...... un jour

[RunCodePhp]

En fait dans ma boite j'ai encouragé les utilisateurs admin à avoir deux onglets, un sur l'admin du site et un sur la partie publique, c'est très pratique dans ceratins cas ...... j'aurais du me taire encore une fois

A ben là, sauf erreur de ma part, ça ne devrait jamais être le cas, car les sessions devraient être différentes.

Enfin, faut voir comment les choses sont faites tout de même.
Mais pour exemple, de mon coté la partie admin et la partie public sont 2 domaines différents (la partie admin est un sous domaine en faite : admin.domaine.com).
Coté session, c'est géré dans la Bdd, la même table pour les 2, mais leur gestion reste néanmoins séparée (il y a un champ "espace" qui stock le nom de la partie d'ailleurs).
De plus, le nom des sessions sont différents (le session_name).
Toujours est il que je navigue tout le temps des 2 cotés en même temps, dans 2 onglets, j'ai jamais eu ce genre de problème, et pourtant j'enregistre aussi l'historique dans les session pour y faire à peu près la même chose que toi.


De ton coté, les 2 parties seraient dans le même domaine, et du coup, c'est la même session dont il s'agirait, la même qui est reprise, conservée.
C'est là le problème.
Mais là, je ne vois pas trop comment résoudre ça sans tout chambouler.
Peut être définir 2 noms différents pour les session selon les parties ?
En tout cas, il te faut 2 sessions différentes pour les 2 partie, ça me parais évident (peu importe la manière).

[manuscle]

Effectivement j'ai le même domaine pour la partie publique et admin....
C'est vrai que faire un sous domaine pourrait résoudre le problème, mais ça fait changer trop de choses niveau code....
J'y penserais pour une version future!

[RunCodePhp]

C'est vrai que faire un sous domaine pourrait résoudre le problème, mais ça fait changer trop de choses niveau code....

Je t'ai peut être mis sur une mauvaise piste en disant ça, mais auparavant les 2 parties étaient dans le même domaine, et ce n'est pour autant que ça causait un problème.

Penche toi sur le noms des sessions, d'avoir chacun les siens, il y a des chances que ça soit plus simple à faire (à réparer) qu'on le pense.

Puis j'ai tendance à penser que ça devrait être indispensable de le faire, car ce phénomène d'historique, ça pourrait être l'arbre qui cache la foret.
En gros, et théoriquement bien sûr, les données d'un utilisateur coté admin devraient être très différentes de celles coté public (voir radicalement), ce qui fait qu'en navigant ainsi en parallèle, quelqu'un qui normalement serait de type "public" trainerait avec lui des données "admin", et cela sans cesse.
Ce n'est théoriquement pas normal.
Tu devrais t'en apercevoir en scrutant les sessions.
En résumer, il te faudrait résoudre ce truc.
Enfin, tout ça sauf erreur.

Si tout cela se confirme (bien malheureusement), une solution provisoire, en attendant de réparer serait de leur dire d'utiliser 2 navigateurs différents, ça débouchera inévitablement sur 2 sessions différentes.
(Faudra pas basculer dans les 2 parties avec le même navigateur)


Le fait de séparer les 2 parties en 2 domaines, c'est mon coté parano qui m'a amené à faire ainsi.