Discussion :

[alain31tl]

Je pense avoir été tout aussi pertinent dans mes réponses, tout autant que les vôtres.
Et preuve en est la démo.
Le reste , c'est du blabla technique.
Et je souris à l'idée qu'un cookie puisse rester sur le poste utilisateur sans qu'il puisse être utile , alors qu'il vient d'être détruit en session serveur.
Quel intérêt quand on passe directement en page2.php ???
Il est inopérant.
Enfin, bref, je conçois que nous ne pouvons pas toujours avoir la même approche sur un sujet.
D'ailleurs, il y aurait bcp moins d'intervenants.
Les échanges, c'est nourrisant pour nos expériences respectives.
Mais je ne souhaite pas jouer au jeu du borné.

En ce qui me concerne, ce qui m'interresse au premier chef, ce n'est la théorie xbidule, mais le résultat par la pratique en entreprise.

Maintenant, si on me considére comme un trouble-fête dans le sujet présent, j'éteinds mes leds et vous laisse vos spots éclatants.
Bye !

[Edit]
Tout comme les tiennes, les docs foisonnent, à chacun de prendre l'info qui l'interresse et de l'interprêter à sa façon...et surtout les tester en les mettant en pratique.
C'est mieux que la lecture et la théorie.

Sessions

J'ai rien inventé.

[RunCodePhp]

Je pense avoir été tout aussi pertinent dans mes réponses, tout autant que les vôtres.

Non justement, et je t'assure que tu te fait une idée fausse sur certains points.
On est 2 d'ailleurs à le ressentir, ce n'est pas une conspiration, juste un constat.
Faut donc pas le prendre mal, faut juste clarifier les choses, et tu verras que ce sera bénéfique.
Il est là le grand intérêt des échanges sur un forum


En tout cas, absolument tout dépend des échanges, des requêtes HTTP qu'il y a entre le poste client est le serveur, donc des contenus échangés entre les 2.

... à chacun de prendre l'info qui l'interresse et de l'interprêter à sa façon

Il n'y a pas 36 manières d'interpréter le mécanisme des sessions, il n'y en a qu'une seule, et c'est celle que Php à mis en place.
La base est très simple : Il faut qu'il y ait un échange permanent du nom de la session et de valeur de l'id de la session (au minimum) entre le poste client et le serveur, c'est tout.
Sans cette échange d'infos, il n'y aura pas de persistance sur les données en question, c'est tout simplement impossible.
Là où ça diffère beaucoup, voir énormément, c'est la manière de faire ces échanges, et de la gestion de ces informations.

Cet id de session est enregistrés temporairement sur le serveur distant, et demeure tant qu'on ne quitte pas le navigateur.

Ceci est aussi une idée fausse.
Le fichier de session créé coté serveur ne sera détruit que sous 2 conditions :
1/ Le serveur reçois requête HTTP qui contient les infos (Cookie ou URL) correspondant à une session.
Si la session (date de mise à jour du fichier) est expirée, le fichier sera détruit.
2/ Lorsque que le Garbage Collector (le ramasse miette coté serveur) est déclenchée, donc parcourt chaque fichier de session et analyse le temps d'expiration. Chaque fichier de session expiré sera détruit.
Le fichier peut dans ce cas là resté présent sur le serveur bien longtemps après que l'utilisateur ait fermé sont navigateur, voir mettre à la poubelle le PC.

Il n'y aucun rapport directe entre le navigateur et le fichier de session sur le serveur, encore une fois, tout repose sur les infos échangés entre les 2.

Petite parenthèse au passage.
Tous les navigateur ne suppriment pas systématiquement les cookies à la fermeture, les navigateurs permettent de gérer les cookies de différentes manières.
Sur FireFox par exemple il y a 3 choix :
- Soit détruire les cookies lors de la fermeture du navigateur
- Soit de détruire les cookies lorsque la date est expirée.
- Soit de demander à chaque fois
Les chose sont encore un peu plus nuancées que ça.

Un moyen simple de voir ce qu'il y a dans les entêtes HTTP, c'est les fonctions :
get_headers() : get_headers('http://www.domaine.com/page.html', 1)
apache_request_headers()
Avec ces 2 fonctions, tu auras le contenu des entêtes des échangés (client/serveur).
S'il y a un cookie, il sera présent dans ces entêtes.


Le principe général est en faite très simple, et comme je l'ai dit plus haut, tout est une question d'échange entre client/serveur.
Admettons que cela se fasse par cookie.

1/ Et bien lorsque le client (navigateur) lance pour la toute 1ère une requête HTTP, le navigateur analyse parmi la liste des cookies sur le PC s'il y a un cookie non expiré en rapport avec le domaine que l'utilisateur demande.
La requête HTTP est envoyée vers le serveur sans cookie vu que c'est la 1ère fois, il n'y a pas de cookie.

2/ Le serveur reçois la demande, et la traite, donc entre autre analyse le contenu de l'entête HTTP, et remarque qu'il n'y a pas de cookie.
Et bien dans ce cas présent, lors du session_start() ce sera obligatoirement une nouvelle session, un nouveau fichier de créé coté serveur.
Une fois que tous les traitement effectués, le serveur enverra une réponse vers le client, et dans l'entête le serveur rajoute automatique un cookie.

3/ Le poste client reçois la réponse, analyse l'entête, et détecte la présence du cookie.
Le navigateur créera (théoriquement) le cookie sur le PC.

4/ L'utilisateur lance à nouveau une requête HTTP, le navigateur analyse les cookies.
Cette fois, un cookie existe en rapport avec le domaine demandé, sa date n'est pas expirée, et bien cette info sera rajoutée dans l'entête envoyée via HTTP.

5/ Le serveur reçois la nouvelle demande, la traite.
Cette fois, le serveur remarque le présence du cookie, ce qui fait que le serveur récupérera le fichier de session correspondant (le dé-sérialisera entre entre autre), et toutes ces infos seront stockées dans le tableau $_SESSION.

... etc, etc ...


Bref ... sans cette échange, la persistance sera impossible d'obtenir, il faut qu'il y est au minimum une info du client qui dira que c'est lui qui avait fait une demande (requête HTTP) il y quelque temps de ça.
C'est grâce à cette info qu'on parviendra à récupérer d'autres infos (le fichier de session coté serveur) en rapport ce client là, et pas un autre.
Ce mécanisme et à la base simple, mais les postes clients sont tellement différents qu'il est très compliqué d'avoir la certitude d'avoir affaire au mêmes clients (ou personne).
Le cas classique c'est les moteurs de recherche qui n'acceptent pas de cookie, donc dans ce cas là, démarrer une session n'est pas forcément ce qu'il y a de mieux à faire.


Et c'est là que les ennuient commencent, car si l'utilisateur à configuré coté navigateur de ne pas accepter de cookie, le navigateur ne créera pas de cookie, c'est le problème que rencontre Beegees.
Pour pouvoir conserver cette persistance des données de session à chaque échange, donc tout au long de la navigation, et il n'y aura pas d'autres choix que de rajouter le couple nom de la session et id de la session dans toutes les URLs.
Mais comme ce mécanisme est reconnue comme un manque de sécurité, sans compter que ce n'est pas totalement fiable, et bien si on ne le fait pas, c'est foutu, il n'y a pas d'autres solutions.

L'approche qu'il faudrait avoir concernant les sessions/cookies, c'est de prévoir dans son application de ne pas démarrer systématiquement la gestion des sessions, donc de prévoir que le site Web fonctionne sans démarrage de la session, ou alors ne serait qu'une partie du site, au moins la page d'accueil.
C'est à mon sens la meilleur façon procéder.


Tout ce blabla pour dire qu'il n'y a pas 36 solutions pour cette persistance des données en session :
- Soit les échanges se font pas URLs (je résume)
- Soit les échanges sont basés sur un cookie. Le cookie étant le moyen le plus sécurisé et plus sûr, donc on peu dire que pour Beegees c'est quelque peu "mal barré" comme l'a si bien dit Seb. dès le début.
J'en connais pas d'autres, je ne crois pas qu'il existe d'autres moyens d'échange.

[Séb.]

Merci

[ThomasR]

Juste histoire de faire bref :

@alain31tl : l'appel de session_start() provoque la création d'un cookie que l'on appelle "cookie de session", permettant de stocker l'identifiant de session.
Cet identifiant de session est transmis ensuite à chaque requête (comme n'importe quel cookie) afin que PHP, qui a stocké les informations relatives à ces sessions sur le serveur, puisse savoir que le client qui visite le site a une session associée (il va chercher les informations de session pour la session dont l'identifiant est dans le cookie).

[alain31tl]

Juste histoire de faire bref :

Bonsoir Thomas

Ca tombe bien, moi aussi je préfére le bref aux romans.

On est ok!

Mais pourquoi, je n'ai pas de réponse à ma question précédente, et je cite :

.... Et je souris à l'idée qu'un cookie puisse rester sur le poste utilisateur sans qu'il puisse être utile , alors qu'il vient d'être détruit en session serveur.
Quel intérêt quand on passe directement en page2.php ???
Il est inopérant....

Je fais référence au simple exemple émis en page précédente.

Alors, certes, on me rabâche la même réponse:
Si, si, il y a un cookie de session.
Mais si il est détruit côté serveur, il n'y a plus de référant côté poste utilisateur...par conséquent inopérant.

C'est la raison pour laquelle, je me faisais insistant (légitimement au travers de l'exemple cité) et en m'évertuant à souligner cet état de fait... qu'il ne fallait pas confondre :
- Session serveur
- Session pc/utilsateur

Cause Job, désolé pour le retard à donner suite.

[Séb.]

Re

.... Et je souris à l'idée qu'un cookie puisse rester sur le poste utilisateur sans qu'il puisse être utile

Il n'y a pas de cookie restant sur le poste client.

, alors qu'il vient d'être détruit en session serveur.

Aucun cookie n'est jamais présent sur le serveur, en conséquence il ne peut être détruit.

Quel intérêt quand on passe directement en page2.php ???
Il est inopérant....

Pas compris.

[RunCodePhp]

Mais pourquoi, je n'ai pas de réponse à ma question précédente

Parce quelle comporte une erreur de syntaxe déjà.
De plus, les réponses sont dans toutes les explications qu'on tente de te donner, et qui à l'heure actuelle devraient te permette de prospecter un peu plus loin, ne serait-ce en utilisant les 2 fonctions dont je faisais allusion, sans compter des echo sur session_name(), session_id(), print_r($_SESSION), print_r($_COOKIE), etc, etc ...
Le niveau que tu as te permet très largement de prospecter un peu plus, et non pas prendre un banal essai (un banal echo $name) comme "argent comptant", ne crois tu pas ?

Code alain31tl :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
session_start();
 
echo $name;
// elle est bien là.

Ton exemple contient une erreur, car on fait référence à $name qui n'existe pas, car pour faire référence à la variable de session "name" il faudrait faire echo $_SESSION['name'].
Théoriquement Php aurait dû te retourner une erreur.
Cette erreur était elle affichée d'ailleurs ?

Sinon, ça sous entend que le register_global du php.ini serait activé, car ceci permet d'accéder directement aux variables sans passer par les tableaux super globaux.
Mais n'empêche que je ne suis pas certain que ça soit le cas pour les sessions (à confirmer donc).
M'enfin, ça fait des années qu'on dit qu'il ne faut pas activer le register_global pour raison de sécurité entre autre.

Et je souris à l'idée qu'un cookie puisse rester sur le poste utilisateur sans qu'il puisse être utile , alors qu'il vient d'être détruit en session serveur.

C'est tout à fait possible d'avoir des cookies qui ne servent à rien au niveau de son navigateurs (coté client), tout comme avoir des fichiers de sessions (coté serveur) tout aussi inutile, je dirais même que c'est courant.
Je ne vois vraiment rien ici qui prêterait à sourire.

Cependant, on ne sait pas vraiment ce que tu veux démontrer.
D'ailleurs, qu'est-ce que tu souhaite démontrer ?

C'est la raison pour laquelle, je me faisais insistant (légitimement au travers de l'exemple cité) et en m'évertuant à souligner cet état de fait... qu'il ne fallait pas confondre :
- Session serveur
- Session pc/utilsateur

Tu fait encore un amalgame, car coté client il n'y a pas de session, mais juste des cookies, ce n'est absolument pas la même chose.
- Session serveur
- Cookie pc/utilisateur

Le fichier de session coté serveur contient toutes les données (qui aboutiront à des variables de sessions), dans ton exemple c'est le cas de "name" avec comme valeur "ALAIN".

Le Cookie coté client lui ne contient aucune donnée, "name" lui est totalement inconnu, donc innaccéssible, il contient juste :
- Un nom (PHPSESSID par défaut)
- 1 seule valeur qui doit être l'équivalent de l'ID de la session correspondant
- Le domaine dont il appartient
- Et une date d'expiration
c'est tout.


Encore un très loooong discourt, mais que je tu, j'suis du genre bavard quand j'm'y mets.

[alain31tl]

echo $name;
// elle est bien là.
[/CODE]Ton exemple contient une erreur, car on fait référence à $name qui n'existe pas, car pour faire référence à la variable de session "name" il faudrait faire echo $_SESSION['name'].
Théoriquement Php aurait dû te retourner une erreur.
Cette erreur était elle affichée d'ailleurs ?

Tu as essayé au moins ?
Désolé de te contredire mais la variable $name s'affiche bien en page 2 .
La $_SESSION['name'] est initiée en page 1.

[Séb.]

Désolé de te contredire mais la variable $name s'affiche bien en page 2 .

Tout dépend de la config de PHP. Chez moi par exemple j'ai une erreur "undefined variable".
$name, variable de session de $_SESSION['name'], ne s'affichera que si register_globals est à On.
Or register_globals est une directive dépriciée depuis des années et obsolète depuis PHP 5.3 ( http://www.php.net/manual/fr/ini.cor...gister-globals ).

[alain31tl]

OVH ne semble pas avoir le même avis sur la dépréciation de cette directive.
Toutes les offres d'hébergements sont paramétrées ( par défaut) avec register_globals à 'ON`.
Et ce sont des professionnels, qui travaillent avec des clients également professionnels.
Ce serait une grosse négligence de leur part, ne crois-tu pas ?

[Séb.]

OVH ne semble pas avoir le même avis sur la dépréciation de cette directive.
Toutes les offres d'hébergements sont paramétrées ( par défaut) avec register_globals à 'ON`.
Et ce sont des professionnels, qui travaillent avec des clients également professionnels.
Ce serait une grosse négligence de leur part, ne crois-tu pas ?

OVH n'a pas le choix, il faut bien qu'ils fassent tourner le max de scripts dans des conditions pas toujours heureuses.

Quant à leurs clients qui développent avec register_globals à On, en connaissance de cause ou pas, et bien je pense que c'est effectivement une énorme négligence de leur part. Ils s'en rendront compte quand ils voudront utiliser les dernières nouveautés de PHP et que leurs scripts ne fonctionneront plus.

Idem pour les magic-quotes.

[alain31tl]

De quelles dernières nouveautés parles-tu ?
Les offres d'actualité comportent PHP 5.3 (entr'autres) et register_globals à On.
Cela plus de 10 ans qu'ils sont dans ce métier.

[Séb.]

De quelles dernières nouveautés parles-tu ?

http://php.net/releases/5_3_0.php (dont un goto )

Les offres d'actualité comportent PHP 5.3 (entr'autres) et register_globals à On.

Dans la doc à propos de register_globals http://www.php.net/manual/fr/ini.cor...gister-globals tu trouveras :

Avertissement
Cette fonctionnalité est OBSOLETE depuis PHP 5.3.0. Nous vous encourageons vivement à ne plus l'utiliser.

Les directives obsolètes disparaîssent des releases suivantes.

Cela plus de 10 ans qu'ils sont dans ce métier.

Je ne sais pas de qui tu parles mais quoi qu'il en soit ce n'est pas pour cela qu'ils sont sur la bonne voie

[RunCodePhp]

+ 1000 Seb

Tu as essayé au moins ?

Non, car je n'essaye pas un code qui de toute évidence est obsolète.
Ca fait des lustres que la communauté Php recommande vivement de désactiver cette directive register_globale.
Puis si tu avais lu, j'avais évoqué que ce code pouvait fonctionner que si cette directive était activée.
A croire que tu ne lis pas ce dont on tente de t'expliquer.

OVH ne semble pas avoir le même avis sur la dépréciation de cette directive.
...
De quelles dernières nouveautés parles-tu ?
Les offres d'actualité comportent PHP 5.3 (entr'autres) et register_globals à On.
Cela plus de 10 ans qu'ils sont dans ce métier.

Tu persiste vraiment à tirer de mauvaises conclusions.
Seb. te l'a pourtant expliqué, mais tu ne veux rien entendre.

Les hébergeurs ne sont pas des développeurs Php, ce n'est pas leur métier, leur Job c'est plutôt des administrateurs systèmes, de proposer des environnements de développement pour leur client, ce n'est franchement pas la même chose.
Il me parait évident que leurs offres se doivent "toucher" le plus large publique (clients) possible.
Donc qu'ils activent ou pas cette directive n'a aucune importance, c'est aux clients codeurs/développeurs d'adapter/modifier ça (php.ini, .hraccess, ini_set, etc ... peu importe) car tout hébergeur digne de ce nom le permettent.

Bref, c'est pour des raisons purement économique qu'ils font ça.
Ca tombe sous le sens pourtant, non ?

Mais au niveau de Php, il est bien précisé ceci :
http://www.php.net/manual/fr/ini.cor...gister-globals

Depuis » PHP 4.2.0, la valeur par défaut de cette directive est off.

Depuis Php 4.2.0, donc depuis des lustres.
Il faut se fier à la Doc de Php, c'est elle la référence, pas à ce que font ou proposent les hébergeurs.


La conclusion qu'il faut en tirer de tout ça :
C'est que tu viens justement de donner une des raisons pour laquelle il est vivement recommandé de désactiver cette directive, du fait du comportement déroutant ou/et confusion quelle provoque sur les données.

Tu t'es fait tout simplement piégé sur le fonctionnement/comportement des sessions à cause de cette directive, du coup tu en a tiré une mauvaise conclusion, une "idée reçue".
Donc ton essai n'a rien démontré du tout, et c'est pour ça que personne n'a réagit.
Le register_global aurait été désactivé, tu n'aurais pas pu exploiter directement $name en page 2, et tu n'aurais pas fais la même conclusion.

[alain31tl]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<?php
session_start();
 
$name="ALAIN";
 
$_SESSION['name'] = $name;
?>

Cela signifie que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$name= $_SESSION['name'];

C'est juste une question.

[RunCodePhp]

C'est juste une question.

Et bien oui, et désactiver le register_global par la même occasion.

Je ferme le navigateur.
Et je refais un test, mais cette fois en me rendant directement en page2.php.
Résultat ? Niet !

Simplement parce que la première session a été détruite, et qu'il n'y aucun cookie sur ma machine.

Si on reprend t'a démonstration, et bien tu change un poil les choses, comme modifier coté options des cookies sur FireFox, de choisir -> "leur expiration".

Et bien cette fois ce même essai fera que même après avoir fermé le navigateur, la valeur de $name (ou $_SESSION['name'] peu importe) s'affichera.

Ca démontre quoi ?
Que le fichier de session n'a pas été supprimé coté serveur comme tu le prétend (c'est l'idée reçue), mais c'est justement du faite qu'il est toujours présent qu'il est possible de reprendre ses informations lors d'une requête HTTP, cela jusqu'à sa date d'expiration.

Cette fois, le cookie coté client (navigateur) a été conservé, du coup on peu fermer le navigateur autant de fois que l'on veut, pointer vers page2, tout ça jusqu'à sa date d'expiration comme le stipule l'option.

[alain31tl]

Si on reprend t'a démonstration, et bien tu change un poil les choses, comme modifier coté options des cookies sur FireFox, de choisir -> "leur expiration".

Et bien cette fois ce même essai fera que même après avoir fermé le navigateur, la valeur de $name (ou $_SESSION['name'] peu importe) s'affichera.

Ca démontre quoi ?
Que le fichier de session n'a pas été supprimé coté serveur comme tu le prétend (c'est l'idée reçue), mais c'est justement du faite qu'il est toujours présent qu'il est possible de reprendre ses informations lors d'une requête HTTP, cela jusqu'à sa date d'expiration.

Cette fois, le cookie coté client (navigateur) a été conservé, du coup on peu fermer le navigateur autant de fois que l'on veut, pointer vers page2, tout ça jusqu'à sa date d'expiration comme le stipule l'option.

ET bien non !
Paramétres :
FF version 3.6.11
Acceptation des cookies jusqu'à leur expiration.
Vider l'historique décochée
Désolé !
page2.php ==> Niet!
L'exemple était simpliste pourtant, et il ne méritait pas d'être plus compliqué pour schématiser une situation, et encore moins d'être singularisé par vos soins.

[RunCodePhp]

ET bien non !

Mais si.
Ton problème, c'est que tu te contente de peu, tu ne cherche pas à comprendre (on est particulièrement insistant pourtant), et pire, tu persiste à tout faire pour conserver ton "idée reçue".

Bon, je n'ai pas prospecter plus loin (pas le temps, mais c'est peut être lié au path, domaine, j'en sais rien, peu importe), mais en rajoutant simplement ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

setcookie(session_name(), session_id(), time() + 3600, '/');

je ferme le navigateur, puis re-pointe sur page2.php, je récupère donc bel et bien la même session.
Donc le fichier de session est toujours resté là coté serveur, ça c'est une certitude.

D'ailleurs, de mon coté sachant très bien que le fichier de session est toujours là, pour résoudre ce problème la réflexion était :
- Comment faire pour le navigateur ne supprime pas le cookie (de session) afin qu'il puisse le renvoyer via HTTP même après fermeture ?

C'est le raisonnement que tu aurais dû avoir, surtout après les nombreuses explications qu'on tente en vain de te donner.


Mais peu importe, c'est parfait comme ça, ne change rien à ton essai.
Donc comme tu constate que le cookie (de session) coté navigateur est détruit à la fermeture (même en précisant "à l'expiration"), et bien fait le plusieurs fois, 5 ou 6 fois minimum.

Après, si tu fais ce teste en local, tu dois au moins savoir où sont stockés les fichiers de sessions coté serveur.
Par exemple sur Wamp c'est : ...blablabla.../wamp/tmp (donc dans un répertoire tmp de wamp).
Je suppose que ça doit être pareil pour un EasyPhp si tu exploite ce Soft.

Et bien tu constateras qu'à chaque fermeture/ré-ouverture + pointage vers page2 qu'il y a eu autant de fichiers de créés.

Ca démontre quoi ?
Que les fichiers de sessions ne sont pas détruits à la fermeture du navigateur, ils sont conservés dans l'attente qu'on vienne les exploiter.
Ici, il n'y aura que le GC (ramasse miette) qui pourra les supprimer.


Bref ... peu importe les essai, mais il faut vraiment que tu en convienne que le navigateur (coté client) n'agit jamais directement sur le serveur, c'est impossible.
Au même titre que le navigateur n'a pas d'accès directe au contenu du fichier de session coté serveur.
Comment veux tu que quelqu'un comme moi situé à la Réunion, que mon navigateur puisse supprimer ou lire un fichier sur developper.com situé à Paris (à 10 000 Km) ?
C'est physiquement impossible, il faut que tu en convienne.


J'ai vraiment épuisé toutes mes cartouches pour tenter de t'enlever cette fichue "idée reçue".
Pourtant, c'est important de le savoir, car c'est du code totalement illogique que tu risque de faire (si ce n'est pas déjà fait).

[alain31tl]

Tes propos pourrait induire en erreur bon nombre de lecteurs.
Et ceci en refusant d'analyser les intérêts à utiliser telle ou telle méthode.

Je n'ai jamais parlé de probléme réel, mais d'états de faits.

Le choix d'une méthode est conditionné par le type d'application utilisée.

Pour des raisons de sécurité interne (entreprise), on utilisera la méthode session/serveur, c'est à dire à durée de vie temporaire, cette solution étant plus adaptée pour garder confidentielles les informations d'un service à l'autre.
C'est le cas notemment utilisé pour des applications fonctionnant en mode collaboratif.

Je prends pour exemple une de mes applic. (+ de 2 ans) fonctionnant dans un cabinet Député-maire.
Chaque utilisateur dispose de ses codes et peut accéder à des informations, ou pas, suivant les droits qui lui sont octroyés.
L'ennui, c'est que les postes ne sont pas personnels, et n'importe qui peut utiliser tel ou tel PC.
Dans ce cas de figure, tu comprendras que les informations ou les accés à telles ou telles informations ne sont plus protégées si on utilisait ta méthode
des cookies stockées sur le poste utilisateur.

Pour le commun des mortels, cette solution n'a que vraiment peu d'intérêt et l'utilisateur trouvera un certain confort, à ne pas être obligé de se
réidentifier à chaque connexion, et optera pour l'option cookies stockées sur le poste de l'utilisateur.
Dans ce cas là, oui, pourquoi pas, il n'y a pas véritablement de danger particulier.


Maintenant, si tu ne comprends pas ce que j'essaye et à mon tour de t'expliquer, je n'y peux rien et qu'il vaut mieux qu'on en reste là, plutôt que de se crêper le chignon.
Et aprés, à chacun de voir en pratique ce qui lui convient le mieux, et je le répête...en pratique.

PS : En pratique sur un www, et non pas en localhost, c'est plus pertinent.

[Séb.]

Bon, pour résumer :
- register_globals ($foo au lieu de $_SESSION['foo']) est dépréciée et ne sera plus supportée par les versions futures de PHP, c'est un fait ;
- Les sessions PHP utilisent des cookies, c'est un fait.

Ces 2 points ont largement été étayés et prouvés, doc à l'appui.
On pourra y opposer ce qu'on veut, mais les faits sont là.

Bonne soirée