Bonjour
je voudrais savoir si c'est possible de conserver les contenus d'une zone de saisie d'un formulaire (en utilisant la fonction POST) pour plusieurs pages afin de pouvoir les réutilisés sans avoir à les stocker dans une base de données.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
conserver données à utiliser pour plusieurs pages
Bonjour
je voudrais savoir si c'est possible de conserver les contenus d'une zone de saisie d'un formulaire (en utilisant la fonction POST) pour plusieurs pages afin de pouvoir les réutilisés sans avoir à les stocker dans une base de données.
Salut !
Oui c'est tout à fait possible.
Côté serveur : les sessions
Côté client : les cookies
On peut aussi utiliser des cookies côté serveur.Envoyé par transgohan
A+.
Sauf que dans la méthode les cookies ne sont pas stockées côté serveur.
Donc si l'utilisateur a un navigateur qui empêche la création des cookies tu peux oublier, ce qui n'est pas le cas de la session qui peut se passer de cookie, et surtout où les données sont bien dans un fichier sur le serveur.
Salut
Humm, oui et non, je dirais plutôt non.
Le principe de ce couple session/cookie est assez simple.
1/ Au départ on souhaite créer cette session (un session_start pour faire simple).
Dans cette action Php (et Apache) se charge de renvoyer un cookie vers le client.
2/ A ce stade on ne sait pas grand chose, on ne fait que le soumettre.
Théoriquement le client (navigateur) reçoit (dans l'entête) la soumission du cookie en question.
-> Si le navigateur accepte (coté config) les cookies, alors il se chargera de le stocker dans la machine de l'utilisateur.
-> S'il ne l'accepte pas, alors tout se qui suit tombe à l'eau.
3/ L'utilisateur clique ensuite sur un lien, formulaire, etc ... (peu importe), et bien le navigateur va rechercher s'il existe un cookie lié au même domaine que celui du lien (et même le Path aussi, le chemin), et ici il existe (étapes précédentes).
Du coup, le navigateur va récupérer le cookie (on dit cookie de session), et le renvoyer dans l'entête de la requête HTTP (correspondant au lien)
4/ Le serveur reçoit cette requête HTTP, détecte la présence d'un cookie dans l'entête, puis va vérifier parmi les fichiers de sessions s'il y en a un qui correspond selon les infos dans l'entête, vu qu'il en existe un, alors le serveur va fournir dans $_SESSION toutes les données correspondantes de ce couple session/cookie.
5/ et ainsi de suite ... tant que la date d'expiration reste valide.
Donc le cookie reste une données beaucoup plus lié au poste client vu que celui est stocké de ce coté là.
Ceci dit, le serveur effectue un minimum de vérification, sans compter que le cookie de session est disponible dans $_COOKIE (s'il est présent dans l'entête).
En résumer, beaucoup de chose se passe au niveau des entêtes échangés entre client / serveur, et un outil comme FireBug permet de mieux percevoir tout ça.
Ca sous entend qu'il faudra utiliser un autre moyen pour que le mécanisme de session fonctionne, car les sessions ne peuvent pas fonctionner uniquement coté serveur, pas possible.
Et là il n'y aura pas d'autres moyen que de rajouter l'ID de session dans tous les liens et formulaires (tous) pour qu'au clique cette infos soit renvoyée au serveur, ce qui est ici loin d'être génial.
Grosso modo on simule le même principe qu'un cookie (en moins bien).
Pour que ça marche, il faut que cet identifiant soit échangé entre client/serveur et ça en permanence.
Donc entre :
1/ "tous les liens"
ou
2/ "dans l'entête de la requête HTTP" (donc 1 seule fois et un poil caché)
La solution 2 reste bien mieux.
Imposer à se que les cookies soient activés coté client n'est pas une contrainte aussi énorme que ça, je dirais au contraire.
De plus la majorité des utilisateurs ne savent même pas ce que c'est qu'un cookie, et à quoi ça sert, donc rare sont ceux qui les désactives.
Ceux qui les désactivent sont ceux qui savent ce que sait, et bien s'il en veut pas tant pis pour lui, non ?
C'est lui qui se mets les bâtons dans les roues, non ?
Même chose pour Javascript.
En moins bien quand on ne prévois pas cet aspect là dans notre application, chose que je ne conçois pas. Cela peut être tout à fait transparent pour le développeur.Et là il n'y aura pas d'autres moyen que de rajouter l'ID de session dans tous les liens et formulaires (tous) pour qu'au clique cette infos soit renvoyée au serveur, ce qui est ici loin d'être génial.
Grosso modo on simule le même principe qu'un cookie (en moins bien).
Citez moi un seul framework qui n'implémente pas une fonction de création d'url incorporant toute seule l'id de session si besoin ? Cela a été pensé, après si l'on n'utilise pas à un framework à nous de penser à cette éventualité.
Car de toute manière on ne peut contrôler le côté client, on ne peut pas imposer à l'utilisateur d'activer ses cookies s'il veut naviguer sur notre site.
Ce serait aberrant que de voir : "Vos cookies ne sont pas activés nous allons vous rediriger vers un moteur de recherche pour trouver un site dispensant les mêmes services. Ou bien revenez lorsque vous aurez activé vos cookies."
N.B : je serais bien curieux de connaitre les arguments de la personne m'ayant voté en négatif sur mon précédent message, je ne pense pas avoir dis une seule chose de fausse et encore moins ne pas avoir aidé l'auteur du sujet...
Oui, mais je me suis mal exprimer.Car de toute manière on ne peut contrôler le côté client, on ne peut pas imposer à l'utilisateur d'activer ses cookies s'il veut naviguer sur notre site.
Je voulais plutôt dire : Si j'ai un site dont certaines fonctionnalités réclament un cookie, alors on peu très bien ne pas proposer les fonctionnalités en question s'ils sont désactivés.
Ca peu se faire.
Comme par exemple un accès Admin.
Il y a rien de choquant à procéder ainsi (je le fait, et avec des contraintes encore plus élevés).
Par ailleurs, il n'est pas rare de voir des site type e-commerce qui vérifient si les cookies sont activés ou pas, et si ce n'est pas le cas, l'internaute ne pourra ni créer de compte client et encore moins acheter.
Même dans ce secteur ça se fait, c'est dire.
C'est beaucoup plus fréquent que tu ne le crois, ou alors on ne visite pas les mêmes sites Web, mais surtout, tu ne dois pas souvent désactiver les cookies, car il faut les désactiver pour le percevoir.
Puis encore une fois, c'est rare que les utilisateurs désactivent les cookies, idem pour Javascript, donc ce n'est pas (ou plus) une contrainte.
Puis il y a moyen de savoir si le coté client a activer ou non les cookie, suffit pour ça de d'abord tenter de créer un cookie de test (pour exemple), puis tant que ce cookie de test n'est pas renvoyé coté serveur, alors on ne démarre pas les sessions.
Pas de cookie de renvoyé = cookie désactivé.
Très simple.
L'erreur que font tous les débutants, c'est de démarrer une session (session_start) sans savoir si le coté client accepte ou pas les cookies.
Ceci provoque inévitablement une pléiade de fichiers de sessions inutilement si le coté client n'accepte pas les cookies, comme les moteurs de recherche entre autre.
Fort heureusement le ramasse-miette fonctionne plutôt bien, sinon c'est des coups à mettre à genou son serveur.
Puis ce n'est pas une question de FrameWork, car un FrameWork digne de ce nom proposera toujours le choix de mettre les IDs de sessions dans les liens ou pas si on veut, c'est le développeur qui choisi.
Par ailleurs, Php permet de le faire nativement, suffit d'activer la config pour ça, il n'y donc pas besoin de FrameWork pour ça.
Les FrameWork proposent surtout mieux que ça, comme rajouter des jetons, hashage, etc ... histoire de renforcer la sécurité (éviter les vols de sessions par exemple).
De toute manière, mettre les IDs de sessions dans les liens c'est franchement pas une bonne solution, particulièrement si on fait ça dans une partie "publique", qui sous entend que les moteurs de recherche pourraient référencer ces liens avec les IDs en questions.
De même qu'un utilisateur lambda pourra toujours copier un lien avec cet Id et le placer dans son blog, et je ne sais quel site Web, ce qui devient absurde.
Quoi que les moteurs de recherche ont intégrer cet aspect là, et on peu leur dire de les ignorer. Ouf diront certains.
Il y a moyen de faire tout ça proprement, suffit de le prendre en compte.
Mais il faut d'abord savoir comment tout ça fonctionne pour justement savoir les avantages et inconvénients de chaque solution.
Relis bien ce que tu as mis, car ça laisse supposer que les sessions peuvent fonctionner tout seuls coté serveur, sans cookie.N.B : je serais bien curieux de connaitre les arguments de la personne m'ayant voté en négatif sur mon précédent message
Oui, c'est possible sans cookie, à condition de le remplacer par autre chose (info dans les liens).
Nuance, vois tu.
Et il n'y a rien de méchant la dedans, c'est juste des explications, histoire de savoir un peu mieux comment la persistance qui est recherchée fonctionne coté session.
En faite j'avais en pas compris ce que tu disais.
Je t'assure que ce n'est pas moi qui t'es mis ce -1, je ne mange pas de ce pain là.
J'ai jamais utiliser ce truc là, j'estime que ça n'apporte pas grand chose, sinon que de semer la zizanie (ce qui est peut être la cas maintenant).
A la limite des +, pourquoi pas.
Que le coupable lève le doigt (on est pas loin de savoir qui c'est maintenant).
Mes interventions sont "bons enfants", sans arrières pensées, juste histoire d'apporter des compléments d'informations.
Je comprend ton point de vue même si je ne le partage pas.
Pour moi le développeur se doit de palier aux demandes des clients (visiteurs), si le client ne souhaite pas de cookie ou de javascript c'est son droit et je vois même pas en quoi on se doit de le juger. ^^
Je me doutais bien à ton message que ce n'était pas toi, cependant comme tu le dis on vote négativement sans donner de raison. Cela n'a aucun sens et n'apporte rien de constructif à la discussion et ne fait qu'embrouiller l'auteur.Je t'assure que ce n'est pas moi qui t'es mis ce -1, je ne mange pas de ce pain là.
J'ai jamais utiliser ce truc là, j'estime que ça n'apporte pas grand chose, sinon que de semer la zizanie (ce qui est peut être la cas maintenant).
A la limite des +, pourquoi pas.
J'y pense et à mon sens c'est inenvisageable. Un ID de session qui transite dans l'URL c'est la porte ouverte à un vol facile et parfois même involontaire de sessionCitez moi un seul framework qui n'implémente pas une fonction de création d'url incorporant toute seule l'id de session si besoin ? Cela a été pensé, après si l'on n'utilise pas à un framework à nous de penser à cette éventualité.
Je suis d'accord aussi sur ce principe, mais ça reste un idéal.
C'est le coté "devoir" qui me laisse perplexe.
Dans le monde de brut où l'on vit, l'aspect économique est plus important que le coté "idéal".
Grosso modo, si la part d'internaute qui désactive les cookies est très faible (ce qui à mon sens est le cas), alors le développeurs va tout simplement l'ignorer, car offrir cette compatibilité là a sans aucun doute un impacte sur le temps de travail.
Sans compter que le développeur professionnel fera payer ce travail à un client.
Pas certain que le client va apprécier de payer pour une cible aussi faible.
Ne parlons pas de la concurrence aussi.
Puis si on va vers cette direction là, alors il faudrait aller jusqu'au bout, comme dire qu'un développeur se doit de créer des sites Web accessibles à tout personne, y compris ceux qui ont des handicaps : Mal voyant, mal entendant, mains paralysées, etc ...
C'est un vrai cauchemar de faire un site avec autant de contraintes, c'est hyper complexe, il y a énormément de choses à apprendre, et ça, rien qu'au niveau du HTML seulement.
Rares sont les sites qui offrent ça, c'est comme tous les lieux publiques, ils sont fais pour une majorités, ça coûte trop cher sinon.
Un monde brut quoi.
Tu soulèves là des points qui méritent bien la comparaison. Et ça me laisse penseur.
Je t'accorde pour le involontaire même si c'est de l'ordre de 1 pour 10000 (et encore...). Naviguer à un moment où il existe exactement deux sessions valides dont l'identifiant est proche à un caractère près peut presque être nommé dans la catégorie de l'irréel.J'y pense et à mon sens c'est inenvisageable. Un ID de session qui transite dans l'URL c'est la porte ouverte à un vol facile et parfois même involontaire de session
Avec un ramasse miette correct et une bonne configuration du temps d'activité de session (et non une session valide des dizaines d'heures comme on peut en voir sur certains site...) il faudrait vraiment avoir des milliers d'utilisateurs sur le site en l'espace d'une heure et ce de façon journalière. Qui peut se vanter de ça ? Très peu de sites.
Quand au vol facile à cause de l'url... Trois clic de plus sur n'importe quel navigateur permet de changer la valeur d'un cookie.
On est pas en train de balancer un débat qui va forcement dévier de ce que voulait l'auteur du topic là ? xD
Dans le fond, que cette info soit dans le cookie ou dans toutes les URLs, ce risque là existera quand même.Un ID de session qui transite dans l'URL c'est la porte ouverte à un vol facile et parfois même involontaire de session
Il ne faut pas oublier que même si on opte pour un cookie, l'ID s'y trouve à chaque échange entre le client et serveur, le principe est finalement le même que pour les IDS dans les liens.
La seule différence, c'est que l'info se trouve dans l'entête : client vers le serveur, du serveur vers le client (et ça à chaque fois).
L'info n'est pas présente concrètement dans le code HTML, elle est un poil cachée, et elle y est qu'une fois dans l'entête.
Qu'un SID transite en GET ou en en-tête HTTP pour un sniffer ça ne change pas grand-chose, on est d'accord.
Mais pour l'utilisateur lambda qui copie/colle l'URL sur un forum ou un email ça change tout et ouvre grand les portes à sa session.
Cas concret : free.fr fait transiter en clair le SID de la console d'administration d'abonnement dans l'URL, n'importe qui cliquant sur un lien posté récemment sur un forum peut donc y accéder. Je vous laisse imaginer les conséquences.
+1
C'est exactement ça.
Ca la fiche mal quand même d'apprendre de la part de ces internautes qu'ils se retrouvent avec une identification qui ne serait plus la leur à un moment donné.
Je ne citerais pas le Soft, mais il y en a un où c'était assez fréquent.
A mon avis ça doit encore être le cas.
J'ai jamais adhérer de placer ces IDs dans tous les liens et formulaires, j'ai toujours vu ça comme un gros scotch pour "forcer" son site ou le service de fonctionner même si les cookies sont désactiver.
A une époque c'était assez fréquents de voir des copies de liens contenant des IDs, c'était aussi la chasses aux IDs de sessions coté forums.
J'avais de la peine pour ceux qui cherchaient à savoir comment s'en débarrasser.
Grosso modo ils voulaient une chose et son contraire, ce qui équivaut à une impasse.
Mon raisonnement est peut être simpliste, mais il privilégie quand même la sécurité (et la protection des données personnelles qui ne m'appartiennent pas) plutôt que du full accessibilité sans vraiment savoir se que les hackers sont capables de faire.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager