Piwigo.org

nicolas · 2006-07-27 09:00:43

Je n'ai pas totalement terminé de faire mes modifications. Pour répondre au besoin de Radu, revenir au comportement de la version 1.5 et surtout pour avoir plus de cohérence je compte déplacer tout ce qui concerne la connexion/déconnexion dans include/user.inc.php . Pour le moment il y en a dans index.php, dans identification et ça ne me plait pas.

plg · 2006-07-27 10:10:10

nicolas a écrit:
z0rglub a écrit:
Reprenons :

* 1 utilisateur possède N clefs d'auto-connexion
pourquoi N ? Je suis d'accord si N=0 ou 1

Il faut N (0 à+infini) clefs d'auto-connexion par utilisateur car certains utilisateurs sont génériques. Et puis parce qu'on peut vouloir une connexion longue à la maison et des connexions courtes au travail (je suis pas certain que les 2 notions soient liées dans ton modèle).

nicolas a écrit:
z0rglub a écrit:
Il n'y avait pas les 2 niveaux "session" et "auto-connexion". Là, on ajoute de la complexité, j'espère que cet ajout de complexité a du sens et apporte un réel avantage à PhpWebGallery. Pour le moment, je n'en vois pas, mais ça va venir, n'est-ce pas ?
Je ne vois pas les choses ainsi. Il y a une session utilisateur et un mécanisme indépendant (auto-login) pour facilier la vie des utilisateurs en ne leur demandant pas leur login/mot de passe à chaque visite.

Exactement comme en 1.5 en somme. Je suis désolé d'être insistant, mais j'aimerais que ce topic soit l'occasion d'expliquer :

1. en quoi une session longue comme en 1.5 est dangereux ?
2. quels sont les avantages des sessions standard PHP ?

Pour rappel, le nouveau mode de gestion des sessions en 1.6 n'apporte encore rien, si ce n'est des problèmes. Pour être franc, j'en suis très déçu. Mon sentiment est que pour le moment, on brasse beaucoup d'air pour pas grand chose. Les utilisateurs se fichent complètement de mode de gestion, ils voient uniquement qu'on est passé d'un mode qui marchait à un autre qui a du mal à marcher :-/ pour aucun avantage fonctionnel.

nicolas · 2006-07-27 12:32:20

z0rglub a écrit:
nicolas a écrit:
z0rglub a écrit:
Reprenons :

* 1 utilisateur possède N clefs d'auto-connexion
pourquoi N ? Je suis d'accord si N=0 ou 1
Il faut N (0 à+infini) clefs d'auto-connexion par utilisateur car certains utilisateurs sont génériques.

Désolé je ne comprends toujours pas. Je ne connais pas bien les utilisateurs génériques mais si j'ai bien compris ils ont moins de droit: par exemple ils n'ont pas accès au profil. A mon sens il n'y a aucun intérêt à ce qu'ils aient chacun leur clé.

z0rglub a écrit:
Et puis parce qu'on peut vouloir une connexion longue à la maison et des connexions courtes au travail (je suis pas certain que les 2 notions soient liées dans ton modèle).

Je ne comprends pas non plus. Qu'est-ce qui t'en empêche ?

z0rglub a écrit:
nicolas a écrit:
z0rglub a écrit:
Il n'y avait pas les 2 niveaux "session" et "auto-connexion". Là, on ajoute de la complexité, j'espère que cet ajout de complexité a du sens et apporte un réel avantage à PhpWebGallery. Pour le moment, je n'en vois pas, mais ça va venir, n'est-ce pas ?
Je ne vois pas les choses ainsi. Il y a une session utilisateur et un mécanisme indépendant (auto-login) pour facilier la vie des utilisateurs en ne leur demandant pas leur login/mot de passe à chaque visite.
Exactement comme en 1.5 en somme. Je suis désolé d'être insistant, mais j'aimerais que ce topic soit l'occasion d'expliquer :

1. en quoi une session longue comme en 1.5 est dangereux ?

Plus la session est longue et plus il y a de risque que quelqu'un vole la session d'un utilisateur légitime.

z0rglub a écrit:
2. quels sont les avantages des sessions standard PHP ?

Le fait que ce soit standard justement. Comme n'importe quel autre mécanisme que tu veux utiliser tu as le choix entre celui proposé par php et inventer le tien. php propose nativement un mécanisme de session sécurisé et robuste, à la seule condition de respecter la manière de faire en particulier ne pas allonger la durée de vie des sessions.

z0rglub a écrit:
Pour rappel, le nouveau mode de gestion des sessions en 1.6 n'apporte encore rien, si ce n'est des problèmes. Pour être franc, j'en suis très déçu. Mon sentiment est que pour le moment, on brasse beaucoup d'air pour pas grand chose. Les utilisateurs se fichent complètement de mode de gestion, ils voient uniquement qu'on est passé d'un mode qui marchait à un autre qui a du mal à marcher :-/ pour aucun avantage fonctionnel.

Il n'y a certes aucun avantage fonctionnel (pour le moment. J'ai toujours dans l'idée de mettre plus que l'identifiant de la personne dans la session) mais il y a tout de même un réel avantage: une meilleure sécurité.

rub · 2006-07-27 17:56:12

nicolas a écrit:
z0rglub a écrit:
nicolas a écrit:

pourquoi N ? Je suis d'accord si N=0 ou 1
Il faut N (0 à+infini) clefs d'auto-connexion par utilisateur car certains utilisateurs sont génériques.
Désolé je ne comprends toujours pas. Je ne connais pas bien les utilisateurs génériques mais si j'ai bien compris ils ont moins de droit: par exemple ils n'ont pas accès au profil. A mon sens il n'y a aucun intérêt à ce qu'ils aient chacun leur clé.

Tout dépend de l'algo. Ca peut se faire avec 1 ou N clefs [Pierrick aime beaucoup le N].
En fait, il faut savoir que pour les users génériques:
o il peut y avoir x connextions simumtanées
o il peut y avoir x postes avec l'auto-connect et y postes sans l'auto-connect

=> Il faut simplement que les régles fonctionnent

(C'est les mêmes regles pour les autres utilisateurs car on peut se connecter différement à la maison au boulot ou chez des amis).

De toute façon, avec 1 ou N, c'est transparent pour l'utilisateur.

Inconvénient du 1 clef => rejet de la clef va s'appliquer sur tous les postes
Inconvénient du N clefs => gestion un peu plus compliqué

Personnellement, je ne suis pas partisant ni pour l'un ni pour l'autre, les 2 solutions se valent.

Personnellement, je suis pour les sessions php, car on utilise des éléments standard.

L'application à PWG doit par contre être transparent pour l'utilisateur Lambda!

nicolas · 2006-07-28 11:29:38

Je viens de faire une nouvelle mise à jour: [Subversion] r1511

J'ai regroupé tout le code concernant les session (ouverture de session, logout et auto-login) dans include/user.inc.php

Cela résoud le bug mais merci de me remonter tout éventuel problème.

nicolas · 2006-07-29 15:56:16

Je suis étonné voire un peu déçu de ne pas avoir de retour sur le fonctionnement ou non fonctionnement de l'auto-login que j'ai mis en place.

z0rglub a écrit:
Exactement comme en 1.5 en somme. Je suis désolé d'être insistant, mais j'aimerais que ce topic soit l'occasion d'expliquer :
1. en quoi une session longue comme en 1.5 est dangereux ?
2. quels sont les avantages des sessions standard PHP ?

Pour rappel, jusqu'à la version 1.5 de pwg les sessions n'utilisaient pas le mécanisme standard de php. En fait on n'avait pas de "réelles" sessions mais un cookie "normal" (avec un attribut expire différent de 0) qui permettait de reconnaitre la personne d'une page à une autre après authentification.
Mis à part le problème lié à la mise en place du cookie qui pouvait poser problème si quelqu'un transmettait le lien par mail ou en cliquant sur un lien pointant vers un autre site. Par mail ou en lisant les logs du serveur on pouvait récupérer la valeur du cookie est usurper l'idendité de quelqu'un.

Mais à mon sens le plus gros problème était que cette pseudo-session durait trop longtemps. Une session si on ne change pas la configuration par défaut de php ne dure au maximum que 24 minutes sans activité. Cette durée est sensé protéger l'identifiant de session d'une attaque par force brute (i.e quelqu'un qui essaierait tous les identifiants de sessions possibles jusqu'à en trouver un de valide). Plus cette durée est longue, plus le risque est grand.

chrisaga · 2006-07-29 18:50:18

J'ai l'impression que ça fonctionne plutôt mieux.
Un problème rencontré :
Si le browser plante (FF, mais probablement d'autre aussi) on ne peut pas se reconnecter tant qu'on n'a pas nettoyé les cookies,
ereur de synthaxe SQL que je n'ai pas noté, mais qui cherche id=; mais il n'y a pas visiblement pas de valeur dans l'id.
Si je retombe dessus, je te le note.

<:o)

nicolas · 2006-07-29 21:55:00

chrisaga a écrit:
J'ai l'impression que ça fonctionne plutôt mieux.
Un problème rencontré :
Si le browser plante (FF, mais probablement d'autre aussi) on ne peut pas se reconnecter tant qu'on n'a pas nettoyé les cookies,
ereur de synthaxe SQL que je n'ai pas noté, mais qui cherche id=; mais il n'y a pas visiblement pas de valeur dans l'id.
Si je retombe dessus, je te le note.

<:o)

J'essaie de reproduire cela mais ce que tu dis est étrange car si le navigateur se plante le cookie de session est supprimé. Si tu as coché "se rappeler de moi" tu es automatiquement reconnecté sinon tu dois t'identifier.

chrisaga · 2006-07-29 23:09:05

Effectivement, j'ai regardé, il ne reste plus que le cookie "remember me".
J'ai eu le cas sur tous mes navigateurs après avoir descendu ta mise à jour. Je ne m'en suis pas inquiété.
Puis j'ai fait planter FF en utilisant une fenêtre d'inspecteur DOM périmée, et j'ai de nouveau eu le cas.

Edit
En fait j'ai ce message d'erreur, même quand le browser est fermé proprement :

Code:

SELECT auto_login_key
  FROM phpwebgallery_users
  WHERE id = 
;
[mysql error 1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 3

Dernière modification par chrisaga (2006-07-30 00:10:22)

rvelices · 2006-08-01 01:49:47

Est-ce qu'il y a une raison pour le redirect en auto_login ? Si on clique sur un lien externe (une autre page ou un email) et l'auto_login est executee alors ca me ramene toujours a la page principale.

Sinon ca marche tres bien, mais j'avoue que je ne vois pas en quoi ceci est plus secure que les sessions remember_me qui sont plus longues ...

rub · 2006-08-01 06:53:31

rvelices a écrit:
Est-ce qu'il y a une raison pour le redirect en auto_login ? Si on clique sur un lien externe (une autre page ou un email) et l'auto_login est executee alors ca me ramene toujours a la page principale.

Sinon ca marche tres bien, mais j'avoue que je ne vois pas en quoi ceci est plus secure que les sessions remember_me qui sont plus longues ...

Et avec ($conf['guest_access'] = false), ca boucle en continue sur identification.php sans l'afficher bien sur!

(cf http://forum.phpwebgallery.net/viewtopi … 404#p42404)

Dernière modification par rub (2006-08-01 06:59:34)

rub · 2006-08-01 13:30:23

rub a écrit:
nicolas a écrit:
z0rglub a écrit:

Il faut N (0 à+infini) clefs d'auto-connexion par utilisateur car certains utilisateurs sont génériques.
Désolé je ne comprends toujours pas. Je ne connais pas bien les utilisateurs génériques mais si j'ai bien compris ils ont moins de droit: par exemple ils n'ont pas accès au profil. A mon sens il n'y a aucun intérêt à ce qu'ils aient chacun leur clé.
Tout dépend de l'algo. Ca peut se faire avec 1 ou N clefs [Pierrick aime beaucoup le N].
En fait, il faut savoir que pour les users génériques:
o il peut y avoir x connextions simumtanées
o il peut y avoir x postes avec l'auto-connect et y postes sans l'auto-connect

=> Il faut simplement que les régles fonctionnent

(C'est les mêmes regles pour les autres utilisateurs car on peut se connecter différement à la maison au boulot ou chez des amis).

De toute façon, avec 1 ou N, c'est transparent pour l'utilisateur.

Inconvénient du 1 clef => rejet de la clef va s'appliquer sur tous les postes
Inconvénient du N clefs => gestion un peu plus compliqué

Personnellement, je ne suis pas partisant ni pour l'un ni pour l'autre, les 2 solutions se valent.

Personnellement, je suis pour les sessions php, car on utilise des éléments standard.

L'application à PWG doit par contre être transparent pour l'utilisateur Lambda!

Finalement, après refléxion, je suis pour N clefs.
Une clef pour un couple (user, poste client).

Pourquoi? Car avoir une seule clef c'est un peu comme loggé le mot de passe dans le cookie.
Si on le récupére, on fait ce qu'on veut.

Ce qu'il vaudrait, c'est changer de clef à chaque "auto-login".

Et puisque ca doit fonctionner sur x postes en même temps, il est nécessaire d'avoir x clefs.

Qu'en pensez-vous?

nicolas · 2006-08-01 13:51:07

rub a écrit:
Finalement, après refléxion, je suis pour N clefs.
Une clef pour un couple (user, poste client).

Admettons. Comment caractérises-tu le poste client ? Et comment crées-tu cette clé ? En gros comment ça fonctionnerait ?

rub a écrit:
Pourquoi? Car avoir une seule clef c'est un peu comme loggé le mot de passe dans le cookie.
Si on le récupére, on fait ce qu'on veut.

Non. Il faut définir des actions qui requièrent une nouvelle authentification. Par exemple, même si je suis logué, pour changer mon mot de passe ou mon adresse email je dois redonner le mot de passe actuel.

rub a écrit:
Ce qu'il vaudrait, c'est changer de clef à chaque "auto-login".

Je ne vois pas l'intérêt.

rub a écrit:
Et puisque ca doit fonctionner sur x postes en même temps, il est nécessaire d'avoir x clefs.

Je dirais que tu n'as pas essayé. Ca fonctionne tel que je l'ai fait, mis à part le problème que tu as corrigé.

rub · 2006-08-01 14:52:05

nicolas a écrit:
rub a écrit:
Finalement, après refléxion, je suis pour N clefs.
Une clef pour un couple (user, poste client).
Admettons. Comment caractérises-tu le poste client ? Et comment crées-tu cette clé ? En gros comment ça fonctionnerait ?

Aucune idée.
Je ne sais pas le cookie.
Le plus simple, c'est que le cookie représente le poste client.
Si les cookies sont vidés, effacés, ... il y aura des clefs non et plus utilisé.
=> on peut supprimer en auto les clefs si non utilisé depuis x mois, semaines, années.

=> Mais, il doit y avoir mieux!

nicolas a écrit:
rub a écrit:
Pourquoi? Car avoir une seule clef c'est un peu comme loggé le mot de passe dans le cookie.
Si on le récupére, on fait ce qu'on veut.
Non. Il faut définir des actions qui requièrent une nouvelle authentification. Par exemple, même si je suis logué, pour changer mon mot de passe ou mon adresse email je dois redonner le mot de passe actuel.

Par "on fait ce qu'on veut", c'est deja l'accés aux photos, la personnalisation, etc...
Effectivement, changement de mot de passe, ..., c'est impossible.

nicolas a écrit:
rub a écrit:
Ce qu'il vaudrait, c'est changer de clef à chaque "auto-login".
Je ne vois pas l'intérêt.

Pour éviter, de pouvoir avoir accés aux photos, ... par simple piratage de cookie.

nicolas a écrit:
rub a écrit:
Et puisque ca doit fonctionner sur x postes en même temps, il est nécessaire d'avoir x clefs.
Je dirais que tu n'as pas essayé. Ca fonctionne tel que je l'ai fait, mis à part le problème que tu as corrigé.

x clefs, c'était si l'on change de clef à chaque "auto-login" pas dans ce qui a été livré actuellement.

PS: Sinon, effectivement, je n'ai pas encore testé car j'attends que ca fonctionne avec $conf['guest_access'] = false. ;-)
PS2: heu, je n'ai rien corrigé sur les sessions, juste mis en feedback avec ce qui provoquait l'erreur.

nicolas · 2006-08-01 15:27:39

rub a écrit:
PS: Sinon, effectivement, je n'ai pas encore testé car j'attends que ca fonctionne avec $conf['guest_access'] = false. ;-)
PS2: heu, je n'ai rien corrigé sur les sessions, juste mis en feedback avec ce qui provoquait l'erreur.

J'ai corrigé dans le tronc.
Teste en long et en large et dis moi si le fonctionnement te convient avec tous les particuliers que tu peux rencontrer: plusieurs accès avec le même login, utilisateurs génériques,...
Merci de ton aide.

Piwigo.org

Annonce

#46 2006-07-27 09:00:43

Re: Le fonctionnement des sessions.

#47 2006-07-27 10:10:10

Re: Le fonctionnement des sessions.

nicolas a écrit:

z0rglub a écrit:

nicolas a écrit:

z0rglub a écrit:

#48 2006-07-27 12:32:20

Re: Le fonctionnement des sessions.

z0rglub a écrit:

nicolas a écrit:

z0rglub a écrit:

z0rglub a écrit:

z0rglub a écrit:

nicolas a écrit:

z0rglub a écrit:

z0rglub a écrit:

z0rglub a écrit:

#49 2006-07-27 17:56:12

Re: Le fonctionnement des sessions.

nicolas a écrit:

z0rglub a écrit:

nicolas a écrit:

#50 2006-07-28 11:29:38

Re: Le fonctionnement des sessions.

#51 2006-07-29 15:56:16

Re: Le fonctionnement des sessions.

z0rglub a écrit:

#52 2006-07-29 18:50:18

Re: Le fonctionnement des sessions.

#53 2006-07-29 21:55:00

Re: Le fonctionnement des sessions.

chrisaga a écrit:

#54 2006-07-29 23:09:05

Re: Le fonctionnement des sessions.

Code:

#55 2006-08-01 01:49:47

Re: Le fonctionnement des sessions.

#56 2006-08-01 06:53:31

Re: Le fonctionnement des sessions.

rvelices a écrit:

#57 2006-08-01 13:30:23

Re: Le fonctionnement des sessions.

rub a écrit:

nicolas a écrit:

z0rglub a écrit:

#58 2006-08-01 13:51:07

Re: Le fonctionnement des sessions.

rub a écrit:

rub a écrit:

rub a écrit:

rub a écrit:

#59 2006-08-01 14:52:05

Re: Le fonctionnement des sessions.

nicolas a écrit:

rub a écrit:

nicolas a écrit:

rub a écrit:

nicolas a écrit:

rub a écrit:

nicolas a écrit:

rub a écrit:

#60 2006-08-01 15:27:39

Re: Le fonctionnement des sessions.

rub a écrit:

Pied de page des forums