Piwigo.org

plg · 2006-11-29 15:02:12

Bonjour à tous et plus particulièrement à l'équipe de développement,

Je ne souhaite pas continuer la discussion sur [topic 8313] Le fonctionnement des sessions dans le topic d'origine, mais j'ai quand même besoin d'exprimer ce que je pense des sessions standard implémentées en 1.6.

La raison du changement du système était: utiliser un mécanisme standard et augmenter la sécurité. Je rappelle qu'en 1.5, nos pseudos sessions fonctionnait parfaitement, on ne s'en souciait jamais.

Je suis favorable à l'utilisation des standards. Mais dans le cas présent, ce standard a apporté un code bien plus compliqué (donc inévitablement buggué) sans apporter d'avantage technique.

Concernant la sécurité, on est passé d'un identifiant de sessions à durée de vie maximale potentiellement long (selon la configuration, par défaut à 1 an) à une clef d'auto login inexpirable. J'ai franchement beaucoup de mal à voir l'augmentation de sécurité là-dedans. J'avoue que la sécurité, je m'en moque un peu, qu'elle soit de 7 sur 10 ou 9 sur 10, on parle d'une application de gestion de photos, et de rien d'autre. J'utilise simplement l'argument car il est mis en avant pour l'utilisation de sessions standard.

Ce qui me pousse à exprimer mon mécontentement c'est la franche augmentation de la complexité du code. En conséquence pas mal de bugs s'y sont inévitablement glissés.

Ma conclusion : je souhaite repasser aux pseudo sessions de la branche 1.5. Mon offre : pour la sécurité, je veux bien qu'on passe l'id de pseudo session sur 100 caractères (la force brute, elle a intérêt à bien s'accrocher).

flipflip · 2006-11-29 15:17:13

Salut, je ne vais pas parler de la sécurité. Mais peut être d'un autre avantage des sessions standard. Je n'ai pas creusé cette piste mais est ce que l'utilisation des sessions standard ne permettrait pas d'avoir une comptabilité avec d'autres applications qui utilisent les sessions standard ?

Juste une autre remarque, comme tout nouvelle fonction, les premieres version sont obligatoirement buggé. Donc je ne pense pas que ce soit lié aux sessions.

plg · 2006-11-29 15:34:05

flipflip a écrit:
Salut, je ne vais pas parler de la sécurité. Mais peut être d'un autre avantage des sessions standard. Je n'ai pas creusé cette piste mais est ce que l'utilisation des sessions standard ne permettrait pas d'avoir une comptabilité avec d'autres applications qui utilisent les sessions standard ?

Excellente remarque. Si c'était possible, ce serait vraiment un énorme point positif. Mais à l'heure actuelle, on a déjà du mal à gérer des comptes utilisateur inter-applications, alors les sessions inter-applications, je ne me fais aucune illusion. Et puis avec une fonction "remember me" qui marche bien, ce n'est pas vraiment si important dans la pratique.

Juste une autre remarque, comme tout nouvelle fonction, les premieres version sont obligatoirement buggé. Donc je ne pense pas que ce soit lié aux sessions.

Alors, là c'est un peu fumeux comme remarque ;-). Les pseudos sessions n'ont posé qu'un problème dans mon souvenir : en 1.0.0 (en 2002), j'avais mis l'identifiant de l'utilisateur dans le cookie, et pas d'autre clef, quel boulet.

rvelices · 2006-11-29 15:56:58

Je suis d'accord sur la securite et auto_login_key (il ne change jamais). De mon point de vue une session plus longue (pour remember_me seulement) aurait ete preferable et le code plus simple.

Pour etre honnete je ne vois pas aucun interet de revenir en arriere a la sessions version 1.5 car ca marche bien (je pense) aujourd'hui et il ya eu quand meme pas mal de travail et discussions faites dessus. Ca serait beaucoup de code modifie (avec risque d'erreurs) pour pas grande chose. Par contre je vote pour une simplification du code en virant le auto_login_key et la cookie associee; les sessions avec remember_me seront plus longues.

Pour finir: le avantages que je vois au systeme des sessions PHP est:
- leur expiration est automatiquement prolonge avec chaque access (le remember_me d'1 annee dans la 1.5 peut etre reduit fortement, pas besoin d'une tache de maintenance)
- on peut mettre des choses dans _SESSION a tout moment et ca sera automatiquement sauve sans rien faire
- c'est facile d'ouvrir des sessions PHP pour les visiteurs anonymes si on desire sauver des choses cote serveur (plutot que rajouter une cookie par exemple pour l'ordre de tri des vignettes, etc..)

flipflip · 2006-11-29 16:05:52

Alors, là c'est un peu fumeux comme remarque ;-). Les pseudos sessions n'ont posé qu'un problème dans mon souvenir : en 1.0.0 (en 2002), j'avais mis l'identifiant de l'utilisateur dans le cookie, et pas d'autre clef, quel boulet.

A pas sûr, il me semble avoir lu, et c'est ce qui a motivé le passage au session standard, que dans le cas ou une personne envoyait le lien de son site avec l'identifiant dans l'url, le destinataire reprennait la session de l'utilisateur d'origine.

Et puis avec une fonction "remember me" qui marche bien, ce n'est pas vraiment si important dans la pratique.

En se qui concerne ces fonctions je pense que ça ne devrait même pas exister et se quelle que soit l'application. C'est un manque total de bon sens et de sécurité. Est-ce que vous ecrivez sur votre carte bleu votre code ? A moins que je confonde, mais pour moi remember_me est la case à cocher pour que, lorsque je visite le site 3 jours plus, je n'ai pas besoin de rentrer à nouveau mon nom d'utilisateur et mot de passe.

Excellente remarque. Si c'était possible, ce serait vraiment un énorme point positif. Mais à l'heure actuelle, on a déjà du mal à gérer des comptes utilisateur inter-applications, alors les sessions inter-applications, je ne me fais aucune illusion. Et puis avec une fonction "remember me" qui marche bien, ce n'est pas vraiment si important dans la pratique.

Effectivement, actuellement je ne sais pas comment fonctionne les autres appli que j'utilise (dotclear, punbb, joomla) au niveau des sessions, mais je pense que le couplage de l'externalisation des comptes plus un système de session unifié entre application sera le top, mais comme je le dis souvent :

Et la j'me réveil et je tombe de mon lit !

Dernière modification par flipflip (2006-11-29 16:08:11)

VDigital · 2006-11-29 16:20:03

z0rglub,

Je n'étais pas franchement favorable aux sessions php.
Je souligne que les "gros" problèmes de la 1.6 sont souvent liés aux sessions et que le méchanisme n'est pas si simple du fait des configurations différentes proposées par les hébergeurs.

Tu as raison sur le niveau de sécurité requis par une galerie d'image, et tout ceux qui diront le contraire auraient dû visiter le Mondial 2006 de l'automobile. (Je suis convaincu que certains de ces photographes amateurs cherchent à protéger leurs petites photos alors que des milliers de photos similaires existent ailleurs).

Cependant, même si les sessions php "me chauffent" encore un peu les nerfs, je reste persuadé que ce choix est stratégiquement correct.
Certes le code actuel devra être révisé et alors?
L'auto login a accentué certaines failles, il faut en modérer la portée, n'est-ce pas normal?

Qui sait comment s'interfaceront les galeries privées et les applications de demain?

Je préfère de beaucoup que ce problème reste externe à PWG,
et profiter du fait de ne pas réimplanter une solution maison pour nous orienter vers des idées plus originales telles:
- la représentation des tags par des miniatures (image-tags).
- la mise en page qui devrait en découler des image-tags (la mise en page, c'est un vieux débat, je sais).
- la gestion des langues étendues aux tags (mots), aux catégories, aux descriptions, aux commentaires.

Les sessions nécessitent quelques outils de gestion qui verront le jour, j'en suis convaincu.
On utilisera les sessions pour enregistrer la langue du visiteur en autre, la date de son dernier passage... (Les nouveautés seront encore à revoir).
Pour moi, PWG doit apporter avant tout des idées, et des concepts innovants.

Même si je suis embarassé parfois par ces sessions de malheur (pour ne pas dire plus).
Mon avis très intuitif est de les conserver mais de revoir leur paramétrage.
(Elles n'ont, d'après moi, pas assez été testées en releases candidates.)

8-)

rub · 2006-11-29 18:30:19

Pour moi, ca serait une erreur de faire marche arrière car on risque de se retrouver encore une fois avec des bugs sur les sessions.

Actuellement, les correctifs apportés ont permis de résoudre quasiment, voir tous les problèmes liés aux sessions.

S'il y du code à optimiser à simplifier il faut bien sur le faire.

C'est vrai que le début de la mise en place a été difficile mais à long terme, je pense que ca sera utile.

Je n'apporte rien de neuf à ce qui a été dit mais bon.

Dans ce genre de soucis, la marche arrière aurait du être opté beaucoup, beaucoup plus tot, c'est à dire au moment des devs.
Une fois la version distribuée, rvelices a bossé dur pour que ca fonctionne, ca serait dommage de faire un retour....

rvelices · 2006-11-29 21:38:39

En fait plus je reflechis cote securite plus je me dis que le auto_login_key dans la base de donnee n'est pas genial. Si on veut utiliser toujours la 2eme cookie, le contenu de cette 2eme cookie peut tres bien etre un sha1 du user id, son mot de passe et eventuellement l'IP et/ou user agent. C'est meme plus safe que la clef dans la base.

mathiasm · 2006-11-29 21:52:17

- Utiliser le standard c'est bien, et ça me suffit pour justifier cette évolution
- La complexité actuelle du code est peut-être due à une traduction trop littérale du fonctionnment des sessions 1.5. Il suffirait de reposer des specs propres avec règles de gestion selon les différents cas possibles et on retrouvera beaucoup mieux nos petits (j'ai ouvert la brèche dans le wiki). Et personne n'a signalé que le code n'admettait pas quelques optimisations ;-)
- La TNT ça marchait moyen au début, il n'y a pas eu de retour arrière, ils ont optimisé le code... (petit parallèle osé).

Edit: l'url du wiki pour les feignants

Dernière modification par mathiasm (2006-11-29 22:02:07)

plg · 2006-11-30 10:02:10

Je suis content que ce topic suscite des réactions. Croyez bien que je ne suis pas opposé aux changements, mais quand ils ne semblent rien apporter, sauf des bugs, ça fait réfléchir.

Donc OK pour revoir mon jugement sur les sessions standard, à condition qu'on en voit rapidement (1.7 ?) l'intérêt. Qu'on les utilise pour stocker le mode de tri même pour les anonymes ou génériques, par exemple.

Le parallèle avec la TNT (Télévision Numérique Terrestre) est intéressant, sauf que la TNT apporte tout de suite un plus : meilleure qualité de la réception. Fermeture de l'analogie (wouah, notez le jeu de mot).

rvelices a écrit:
En fait plus je reflechis cote securite plus je me dis que le auto_login_key dans la base de donnee n'est pas genial. Si on veut utiliser toujours la 2eme cookie, le contenu de cette 2eme cookie peut tres bien etre un sha1 du user id, son mot de passe et eventuellement l'IP et/ou user agent. C'est meme plus safe que la clef dans la base.

Peux-tu détailler un peu ton idée ?

aurelien · 2006-11-30 13:23:58

flipflip a écrit:
Et puis avec une fonction "remember me" qui marche bien, ce n'est pas vraiment si important dans la pratique.
En se qui concerne ces fonctions je pense que ça ne devrait même pas exister et se quelle que soit l'application. C'est un manque total de bon sens et de sécurité. Est-ce que vous ecrivez sur votre carte bleu votre code ? A moins que je confonde, mais pour moi remember_me est la case à cocher pour que, lorsque je visite le site 3 jours plus, je n'ai pas besoin de rentrer à nouveau mon nom d'utilisateur et mot de passe.

Si je peux apporter mon grain de seil, j'approuve tout à fait : c'est le boulot de Firefox de retenir mes mots de passe. Avec la démocratisation de Firefox, peut-être que ce genre d'options est appellé à disparaître des projets PHP.
D'ailleurs peut-être d'IE le fait aussi maintenant, comme ils copient tout sur Firefox.

flipflip · 2006-11-30 14:29:11

Si je peux apporter mon grain de seil, j'approuve tout à fait : c'est le boulot de Firefox de retenir mes mots de passe. Avec la démocratisation de Firefox, peut-être que ce genre d'options est appellé à disparaître des projets PHP.

Je pense exactement la même chose pour les gestionnaire de mot de passe intégré au navigateur, ça ne devrait pas exister !

Dernière modification par flipflip (2006-11-30 14:29:34)

rvelices · 2006-11-30 16:29:51

z0rglub a écrit:
Donc OK pour revoir mon jugement sur les sessions standard, à condition qu'on en voit rapidement (1.7 ?) l'intérêt. Qu'on les utilise pour stocker le mode de tri même pour les anonymes ou génériques, par exemple.

Peux-tu détailler un peu ton idée ?

La cookie d'auto login contient le user id en clair et un sha1(#users.username, #users.password). De cette maniere:
- pas besoin de gerer une colonne supplementaire dans les tables
- c'est plus secure car pas de risque du a une clef qui change jamais (ca revient a casser le mot de passe ce qui est toujours un risque)
- en changeant le mot de passe, tous les auto-logins sont invalides

Pour l'utilisation des sessions pour les anonymes il suffit de changer une ligne de code dans user.inc.php (ne pas virer la cookie session quand _SESSION['pwg_uid'] est vide) et appeler session_start si necessaire.

Si tu veux qu'on continue sur cette idee je propose 3 commits (la semaine prochaine):
A. Virer #user_infos.auto_login_key de 1.6
B. Virer #users.auto_login_key d'Alligator
C. Stockage du tri des vignettes pour visiteurs/utilisateurs dans la session pour Alligator

PS. Pour la refonte de l'historique tu pourras utiliser les sessions pour tracker les utilisateurs

plg · 2006-11-30 17:02:01

rvelices a écrit:
La cookie d'auto login contient le user id en clair et un sha1(#users.username, #users.password). De cette maniere:
- pas besoin de gerer une colonne supplementaire dans les tables
- c'est plus secure car pas de risque du a une clef qui change jamais (ca revient a casser le mot de passe ce qui est toujours un risque)
- en changeant le mot de passe, tous les auto-logins sont invalides

Oui, là c'est vraiment bien. On fait plus avec moins.

rvelices a écrit:
Si tu veux qu'on continue sur cette idee je propose 3 commits (la semaine prochaine):
A. Virer #user_infos.auto_login_key de 1.6
B. Virer #users.auto_login_key d'Alligator
C. Stockage du tri des vignettes pour visiteurs/utilisateurs dans la session pour Alligator

OK pour moi, sauf le A. A moins que la sécurité de l'application soit compromise, on ne fait pas de changement dans la base sur une branche stable.

rvelices a écrit:
PS. Pour la refonte de l'historique tu pourras utiliser les sessions pour tracker les utilisateurs

J'avais prévu que l'identifiant de visite soit calculé pour les lignes d'historique sans numéro de visite, rafraîchissement à chaque visualisation de l'historique. Mais le principe du "session = visite" me plaît bien, je vais réfléchir :-)

rub · 2006-11-30 18:06:15

z0rglub a écrit:
rvelices a écrit:
Si tu veux qu'on continue sur cette idee je propose 3 commits (la semaine prochaine):
A. Virer #user_infos.auto_login_key de 1.6
B. Virer #users.auto_login_key d'Alligator
C. Stockage du tri des vignettes pour visiteurs/utilisateurs dans la session pour Alligator
OK pour moi, sauf le A. A moins que la sécurité de l'application soit compromise, on ne fait pas de changement dans la base sur une branche stable.

Moi aussi, j'aime bien tout ca.
Le A partiel, c'est possible. C'est à dire utilisation du sha1 sans laissant la colonne (inutile) pour l'instant?

Piwigo.org

Annonce

#1 2006-11-29 15:02:12

sessions standard en 1.6 Vs pseudo sessions 1.5

#2 2006-11-29 15:17:13

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

#3 2006-11-29 15:34:05

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

flipflip a écrit:

#4 2006-11-29 15:56:58

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

#5 2006-11-29 16:05:52

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

#6 2006-11-29 16:20:03

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

#7 2006-11-29 18:30:19

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

#8 2006-11-29 21:38:39

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

#9 2006-11-29 21:52:17

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

#10 2006-11-30 10:02:10

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

rvelices a écrit:

#11 2006-11-30 13:23:58

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

flipflip a écrit:

#12 2006-11-30 14:29:11

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

#13 2006-11-30 16:29:51

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

z0rglub a écrit:

#14 2006-11-30 17:02:01

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

rvelices a écrit:

rvelices a écrit:

rvelices a écrit:

#15 2006-11-30 18:06:15

Re: sessions standard en 1.6 Vs pseudo sessions 1.5

z0rglub a écrit:

rvelices a écrit:

Pied de page des forums