[SPIP Zone] SPIP-plugin balise session

Archives Zone
1

Salut,
je voulais savoir si ca parraissait logique que pour le plugin #balise_SESSION, on avait a la fois le tableau global auteur_session mais aussi le $_SESSION ?
Ca permettrait aussi d'avoir des valeurs dans le #SESSION même lorsque l'on est pas connecté ?

Fil disait de faire un array_merge dans un message du 03/10( mais dans le core )

Si tu bosses sur la SVN il y a déjà #SESSION dans le core. Avec une
gestion du cache assez fonctionnelle. L'affectation de $auteur_session
se fait à un moment précis (function verifier_session() dans
ecrire/inc/session.php), c'est sans doute pas difficile de lui faire
ici un array_merge($_SESSION) ?

ca semble correct de l'intégrer au plugin ? ( en replacant bien sur ce array_merge pour éviter la surcharge )

Merci

2

#balise_SESSION, on avait a la fois le tableau global auteur_session
mais aussi le $_SESSION ?
Ca permettrait aussi d'avoir des valeurs dans le #SESSION même lorsque
l'on est pas connecté ?

Attention pour l'instant on a l'équivalence :
#SESSION est vide <=> $auteur_session est vide <=> l'auteur n'est pas connecté.

Si on sort de ça il faut faire très attention à ne pas ouvrir de trou
de sécurité quand on jouera avec des contrôles d'accès et des
#SESSION... il faudra donc baser les contrôles d'accès sur
#SESSION{statut}... qui serait vide si non-connecté ?

ca semble correct de l'intégrer au plugin ? ( en replacant bien sur ce
array_merge pour éviter la surcharge )

Je pense qu'il vaut mieux bosser sur la version SVN, et proposer des
évolutions du core.

-- Fil

3

Fil a écrit :

#balise_SESSION, on avait a la fois le tableau global auteur_session
mais aussi le $_SESSION ?
Ca permettrait aussi d'avoir des valeurs dans le #SESSION même lorsque
l'on est pas connecté ?
    
Attention pour l'instant on a l'équivalence :
#SESSION est vide <=> $auteur_session est vide <=> l'auteur n'est pas connecté.

Si on sort de ça il faut faire très attention à ne pas ouvrir de trou
de sécurité quand on jouera avec des contrôles d'accès et des
#SESSION... il faudra donc baser les contrôles d'accès sur
#SESSION{statut}... qui serait vide si non-connecté ?
  

alors la... je vous laisse voir et définir cela
mais amha id_auteur doit définir si on est connecté
et le status le niveau d'authentification ...
ca me parait être les 2 a sécuriser directement dans le core.

  

ca semble correct de l'intégrer au plugin ? ( en replacant bien sur ce
array_merge pour éviter la surcharge )
    
Je pense qu'il vaut mieux bosser sur la version SVN, et proposer des
évolutions du core.

malheuresement je n'ai pas la possibilité d'utiliser la svn ( pour le projet sur lequel je suis a l'heure actuelle )
j'utilise les mots clefs arborescents et je n'ai pas mis a jour ce plugin pour la 1.9.3
plus les autres plugins que je ne maitrise pas...

puis ya bien que toi Fil (encore que t'es pas le seul fou :stuck_out_tongue: ) pour utiliser une svn en prod :slight_smile:

4

Bonjour

Avec une petite discussion avec james, ça semble possible d'utiliser
les Session php.
Une idée qui avait été mise dans mon fork, c'était de définir via cfg
les variable session autorisée.
Ainsi ça limiterai les trou de sécurité.

puis ya bien que toi Fil (encore que t'es pas le seul fou :stuck_out_tongue: ) pour
utiliser une svn en prod :slight_smile:

Tu oublie spip-contrib :slight_smile: C'est nicolas qui fait mumuse avec si je ne m'abuse

Km

5

cam.lafit@azerttyu.net a écrit :

Bonjour

Avec une petite discussion avec james, ça semble possible d'utiliser
les Session php.
Une idée qui avait été mise dans mon fork, c'était de définir via cfg
les variable session autorisée.
Ainsi ça limiterai les trou de sécurité.
  

pas con du tout ca :slight_smile:
mais vu que #SESSION est intégré a 1.9.3 , on ne peut pas dire que cfg soit obligatoire pour cela faut prévoir une config de base sans les varialbes de session perso
donc les sessions php sont absentes de #SESSION mais elle peuvent être ajoutées / modifiées / configurées par une lame du couteau suisse ?

sinon la balise # SESSION est vide lorsque l'on est pas authentifier ( arrétez moi si je me trompe )
et je persiste a dire qu'il serait bon qu'elle le soit même si on est pas authentifier ( avec {id_auteur} et {statut} vide bien sur )
ce serait donc possible avec une lame du couteau ?

Tu oublie spip-contrib :slight_smile: C'est nicolas qui fait mumuse avec si je ne m'abuse
  

oui mais fil et nicolas ont quand même la maitrise de spip pour mettre la main a la patte si une svn ne tourne plus :slight_smile: pas moi ( bientôt j'espére )

6

Yoann NOGUES wrote:

Salut,
je voulais savoir si ca parraissait logique que pour le plugin
#balise_SESSION, on avait a la fois le tableau global auteur_session
mais aussi le $_SESSION ?

ce qui serait illogique, c'est d'avoir deux balises distinctes, ou deux
mécanismes distincts alors qu'on est clairement dans le même besoin et la
même fonctionnalité.

Historique : $auteur_session et le répertoire tmp/sessions/
(antérieurement ecrire/data/), c'est bien de simuler le mécanisme de
session php avec php3 qui ne l'intègre pas. En se limitant à ce dont on
avait besoin. Si vous examinez, un fichier de session spip, c'est un
fichier php avec un tableau associatif dedans, et un cookie qui permet de
récupérer le nom de ce fichier. une session php, c'est un fichier dans
/tmp, avec un tableau associatif sérialisé dedans.

On pourrait d'ailleurs s'amuser (enfin ceux qui veulent hein) à remplacer
intégralement notre mécanisme spipien pas le système de session php,
puisqu'on a aujourd'hui une version minimum php qui est 4.2.0 et je ne
connais pas d'hébergeur qui désactive les sessions php :slight_smile: mais c'est une
autre histoire.

Alors, ensuite, la question est de savoir si on gère une session php pour
tout visiteur, même s'il n'est pas identifié. Ma réponse, c'est que je n'y
vois pas d'inconvénients, seulement, le tableau est bien pratique pour
décider si oui ou non on a un visiteur authentifié. S'il est plein parce
que mergé avec $_SESSION, il faudra tester #SESSION{id_auteur}, bien
l'écrire quelquepart et tout et tout... alors pourquoi pas :slight_smile:

Ce qui manquerait alors, c'est que l'action SPIP puisse être appelée comme
actuellement via un lien (GET pour une valeur) mais qu'on puisse aussi
l'utiliser via un formulaire (POST + gestion de champs multiples)

Enfin, accessoirement, une balise #COOKIE serait peut-être un plus pour
compléter cette fonctionalité.

Fil disait de faire un array_merge dans un message du 03/10( mais dans
le core )

Si tu bosses sur la SVN il y a déjà #SESSION dans le core. Avec une
gestion du cache assez fonctionnelle. L'affectation de $auteur_session
se fait à un moment précis (function verifier_session() dans
ecrire/inc/session.php), c'est sans doute pas difficile de lui faire
ici un array_merge($_SESSION) ?

ca semble correct de l'intégrer au plugin ? ( en replacant bien sur ce
array_merge pour éviter la surcharge )

En SVN et dans ce plugin, l'implémentation ne sera pas la même (on ne gère
pas le cache de la même manière) mais ça serait cool qu'on est le même
niveau de fonctions. On fait d'abord sur le plugin pour SPIP 1.9.2, quand
ça marche et qu'on est d'accord sur l'API, on pourra mettre ça dans le
core, je pense.

--
James

7

Fil wrote:

#balise_SESSION, on avait a la fois le tableau global auteur_session
mais aussi le $_SESSION ?
Ca permettrait aussi d'avoir des valeurs dans le #SESSION même lorsque
l'on est pas connecté ?

Attention pour l'instant on a l'équivalence :
#SESSION est vide <=> $auteur_session est vide <=> l'auteur n'est pas
connecté.

oups, j'ai raté ce mail :slight_smile:

Si on sort de ça il faut faire très attention à ne pas ouvrir de trou
de sécurité quand on jouera avec des contrôles d'accès et des
#SESSION... il faudra donc baser les contrôles d'accès sur
#SESSION{statut}... qui serait vide si non-connecté ?

ca semble correct de l'intégrer au plugin ? ( en replacant bien sur ce
array_merge pour éviter la surcharge )

Je pense qu'il vaut mieux bosser sur la version SVN, et proposer des
évolutions du core.

c'est une autre façon de voir. :slight_smile:

Ce qui m'ennuie, c'est qu'on va ajouter ça, puis ça va donner d'autres
idées et d'autres envies, parce qu'on va pointer d'autres manques et qu'à
force, on va jamais stabiliser la 1.9.3, mais bon ... je fais dans la
procrastination en ce moment, j'aide pas beaucoup à la finir cette 1.9.3,
alors, je me tais :slight_smile:

--
James

8

Yoann NOGUES wrote:

cam.lafit@azerttyu.net a écrit :

Bonjour

Avec une petite discussion avec james, ça semble possible d'utiliser
les Session php.
Une idée qui avait été mise dans mon fork, c'était de définir via cfg
les variable session autorisée.
Ainsi ça limiterai les trou de sécurité.

pas con du tout ca :slight_smile:
mais vu que #SESSION est intégré a 1.9.3 , on ne peut pas dire que cfg
soit obligatoire pour cela
faut prévoir une config de base sans les varialbes de session perso
donc les sessions php sont absentes de #SESSION mais elle peuvent être
ajoutées / modifiées / configurées par une lame du couteau suisse ?

avec Mathieu, on a fait un petit test très cool qui permet de faire de la
variable perso classique qui devient graphiquement interfacée dans CFG si
le plugin est installé. c'est dans TABLE_MATIERES.

pas besoin de sur-couche, ni de rendre tel ou tel plugin obligatoire.

ensuite, j'insiste sur un point : n'en faite pas trop au niveau
configuration/personnalisation, plus c'est compliqué, moins ça marche.

on s'est bien pris la tête (n'est-ce pas Stéphane ;)) pour que la balise
#SESSION soit *simple* à utiliser et c'est un objectif à garder en tête.

Ce que je veux dire, c'est que ceux qui n'ont pas besoin d'info
supplémentaire dans #SESSION et ceux qui veulent ajouter une foultitude de
données doivent utilisé la même fonctionnalité et que ça doit être
transparent pour tout le monde. C'est aussi de l'ergonomie.

sinon la balise # SESSION est vide lorsque l'on est pas authentifier (
arrétez moi si je me trompe )

vrai.

et je persiste a dire qu'il serait bon qu'elle le soit même si on est
pas authentifier ( avec {id_auteur} et {statut} vide bien sur )
ce serait donc possible avec une lame du couteau ?

euh, gardez votre couteau suisse dans vos poches les amis, c'est une
sur-couche, rien d'autre. Ca doit marcher sans. :slight_smile:

--
James

9

James a écrit :

ce qui serait illogique, c'est d'avoir deux balises distinctes, ou deux
mécanismes distincts alors qu'on est clairement dans le même besoin et la
même fonctionnalité.
  

bien d'accord

On pourrait d'ailleurs s'amuser (enfin ceux qui veulent hein) à remplacer
intégralement notre mécanisme spipien pas le système de session php,
puisqu'on a aujourd'hui une version minimum php qui est 4.2.0 et je ne
connais pas d'hébergeur qui désactive les sessions php :slight_smile: mais c'est une
autre histoire.
  

euh pas pour moi :slight_smile:

Alors, ensuite, la question est de savoir si on gère une session php pour
tout visiteur, même s'il n'est pas identifié. Ma réponse, c'est que je n'y
vois pas d'inconvénients, seulement, le tableau est bien pratique pour
décider si oui ou non on a un visiteur authentifié. S'il est plein parce
que mergé avec $_SESSION, il faudra tester #SESSION{id_auteur}, bien
l'écrire quelquepart et tout et tout... alors pourquoi pas :slight_smile:
  

ok bien sur c'est ce que disait Fil je disais {id_auteur} et {statut} a minima

Ce qui manquerait alors, c'est que l'action SPIP puisse être appelée comme
actuellement via un lien (GET pour une valeur) mais qu'on puisse aussi
l'utiliser via un formulaire (POST + gestion de champs multiples)
  

Fil disait de faire un array_merge dans un message du 03/10( mais dans
le core )

Si tu bosses sur la SVN il y a déjà #SESSION dans le core. Avec une
gestion du cache assez fonctionnelle. L'affectation de $auteur_session
se fait à un moment précis (function verifier_session() dans
ecrire/inc/session.php), c'est sans doute pas difficile de lui faire
ici un array_merge($_SESSION) ?
      

ca semble correct de l'intégrer au plugin ? ( en replacant bien sur ce
array_merge pour éviter la surcharge )
    
En SVN et dans ce plugin, l'implémentation ne sera pas la même (on ne gère
pas le cache de la même manière) mais ça serait cool qu'on est le même
niveau de fonctions. On fait d'abord sur le plugin pour SPIP 1.9.2, quand
ça marche et qu'on est d'accord sur l'API, on pourra mettre ça dans le
core, je pense.

--
James

10

je voulais savoir si ca parraissait logique que pour le plugin
#balise_SESSION, on avait a la fois le tableau global auteur_session
mais aussi le $_SESSION ?

Moi ça me semble logique, mais ce qu'il me manque dans l'utilisation de ce plugin, c'est que #SESSION ne soit pas vide s'il y a une session PHP en cours, même si l'utilisateur n'est pas connecté à SPIP.

J'ai bien vu la réponse de Fil indiquant que si on fait ça, des tests utilisés actuellement sur #SESSION vide ou non pour savoir si l'utilisateur est connecté ne fonctionneront plus, donc je cherche une autre solution, l'idée étant de pouvoir avoir une personnalisation des pages en fonction d'une info en session PHP, et donc un cache adapté, sans mettre de code PHP dans les squelettes.

On pourrait d'ailleurs s'amuser (enfin ceux qui veulent hein) à remplacer
intégralement notre mécanisme spipien pas le système de session php,
puisqu'on a aujourd'hui une version minimum php qui est 4.2.0 et je ne
connais pas d'hébergeur qui désactive les sessions php :slight_smile:

Ca me semble une bonne idée pour retirer du code spécifique devenu inutile, et ainsi pouvoir aussi profiter de fonctionnalités supplémentaires comme le stockage en base de données plutôt que fichiers.

Alors, ensuite, la question est de savoir si on gère une session php pour
tout visiteur, même s'il n'est pas identifié. Ma réponse, c'est que je n'y
vois pas d'inconvénients, seulement, le tableau est bien pratique pour
décider si oui ou non on a un visiteur authentifié. S'il est plein parce
que mergé avec $_SESSION, il faudra tester #SESSION{id_auteur}, bien
l'écrire quelquepart et tout et tout... alors pourquoi pas :slight_smile:

Ca ne me semble pas délirant, mais effectivement, attention à bien prévenir ceux qui testent actuellement la présence de #SESSION

-Nicolas

--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002