z0rglub a écrit:

Ce n'est pas un bug. C'est parfaitement voulu. C'est le mécanisme habituelle des sessions en PHP.

C'est conceptuel, mais ce n'est pas parce que c'est habituel que ce n'est pas un bug conceptuel.

z0rglub a écrit:

Il ne faut jamais donner cet identifiant à quelqu'un d'autre.

Oui. Mais tu ne peux pas l'empêcher. Je vous ai montré hier dans un message qu'on pouvait faire des erreurs (l'équipe a reçu un mail avec mon adresse réelle).

z0rglub a écrit:

En branche 1.3, l'identifiant de session était associé à une adresse IP pour améliorer la sécurité, sauf que cela posait de gros soucis pour les utilisateurs derrière un proxy, donc j'ai viré la vérification de l'adresse IP.

Oui. J'allais te proposer l'association, mais c'est exact que les proxy nous embêtent.

volcom a écrit:

il me semblait bien que c'était en rapport avec l'absence de cookie chez certains ... je n'étais pas sûr de moi. Mais j'avais bien lu quelquechose en ce sens il y a quelques temps.

Oui, "au cas où l'écriture du cookie échouerait..."
-----
Une idée comme ça, sans réfléchir aux conséquences, dans la page dans un formulaire (display:none)...?

z0rglub a écrit:

Ce n'est pas un bug. C'est parfaitement voulu. C'est le mécanisme habituelle des sessions en PHP. Après la connexion, l'identifiant de session est dans l'URL au cas où l'écriture du cookie échouerait. Dans 99.9% des cas, l'identifiant de session n'apparaît dans l'URL que sur la premère page après connexion et disparaît ensuite.

Ne pourrait-on pas laisser la possibilite de le faire par cookie? ou au moins alors d'offrir la possibilite de terminer la session? apparemment quand on utiliser la bouton "deconnexion", l'id restre valide après.

z0rglub a écrit:

sauf que cela posait de gros soucis pour les utilisateurs derrière un proxy, donc j'ai viré la vérification de l'adresse IP.

effectivement je confirme. c'etait très penible.

Thierry.

Si la personne n'accepte pas les cookies alors elle ne peut pas se connecter

humm...  bien sur, je suis pour une amélioration de la sécurité, étant très concerné par celà, et je laisse les spécialistes dire de quelle façon il faudra procéder.

Mais :

ne soyons pas parano, PWG est tout de même assez sur. Quelques précautions de base devraient permettre d'être relativement tranquille.

Je voudrais ajouter surtout qu'il ne faut pas que trop de barrières nuisent à l'accessibilité des sites.

Tout le monde n'utilise pas forcément les cookies. Il est hors de question (selon moi) de réserver l'accés aux sites sous PWG aux seuls visiteurs dont les ordinateurs sont configurés pour les accepter. (Même si cette solution peut séduire.)

Je pense en particulier aux visiteurs utilisant des terminaux dans des entreprises dont l'accés à internet est restraint.

.... :o)

Je n'ai pas de solution toute prête... et ne suis peut-être pas très contructif, je veux simplement rappeler que si il faut faire évoluer la sécurité, il faut concerver prioritaire la simplicité d'accessibilité.

merci.

eric.

personnellement, les cookies ne me gènent pas . et dans l'absolu je suis plutot d'accord avec toi.

seulement il y presque autant de systemes et de config différents que de visiteurs..  ( j'exagère évidement ) !
et nous devons aussi en tenir compte.

il faudrait trouver des solutions qui demeurent internes à PWG, sans dépendre de l'ordinateur d'origine du visiteur.

eric.

pour le peu que je comprenne, ça m'a l'air tres bien....  mais là je passe la main, je vous laisse faire.  :o)

merci,
eric.

(on est bien d'accord, on reste sur le mécanisme PhpWebGallery pour la gestion des sessions, on ne passe pas au mécanisme standard PHP ?)

tlegras a écrit:

Une remarque et question si je peux me permettre: il me semble que le choix du systeme de session peut aussi permettre de faciliter (ou freiner) l'integration dans des composants tiers (CMS, forum, etc.). qu'est ce qui est le plus simple a ce niveau? le syteme standard ou l'actuel?

Je ne pense pas que l'intégration avec des composants tiers en particulier avec une authentification unique dépende vraiment du système de sessions choisi.

nicolas a écrit:

J'y vois encore un autre avantage non négligeable: améiorer les performances en mettant en sessions certaines infos réduisant significativement le nombre de requêtes par page. Je pense en particulier à l'arbrescence des catégories. La base de données est souvent le goulet d'étranglement qui freine les performances.

Pas si sûr que le goulet soit au niveau de la récupération, il est aussi au niveau du traitement des données récupérées. Tu cites l'exemple de l'arbre des catégories, alors parlons-en :-).

Si pour la branche 1.5, la table #user_forbidden s'est vue renommée en #user_cache, c'est pour pouvoir accueillir d'autre données que la liste des catégories interdites. Je pensais trivialement au nombre total de photos accessibles. Ajouter une colonne avec l'arborescence des catégories sous forme d'un tableau sérialisé, ce serait une excellente idée.

Mettre ce tableau dans la session, je suis contre. A quel moment ce tableau doit il être reconstruit ? A chaque fois que l'administrateur opère dans la zone administration. C'est pour cela que dans admin.php, il y a une purge de #user_cache. Complètement inutile de reconstruire ces données à chaque session, et pire, dommage de supprimer toutes les sessions parce qu'elles stockent des données obsoletes si l'administrateur opère alors que des utilisateurs naviguent dans la galerie.