[spip-dev] [3.2.11] #FORMULAIRE_LOGIN et problème de confidentialité (sécurité ?)

Dev
1

Bonjour à tous,

  J'ai un comportement surprenant avec la balise #FORMULAIRE_LOGIN qui
est appelée d'un squelette comme ceci :

[(#SESSION{id_auteur}|non)
    [(#REM) Méchant hack pour ne pas avoir deux formulaires
            de login sur la même page]
    [(#ENV{mfx_login_responsif}|=={non}|oui)
        [(#ID_ARTICLE|=={195}|non)
            #FORMULAIRE_LOGIN{#SELF}
        ]
        [(#ID_ARTICLE|=={195}|oui)
            <p>Connexion en cours</p>
        ]
    ]
    [(#ENV{mfx_login_responsif}|=={oui}|oui)
        <div class="login">
            <a href="#URL_ARTICLE{195}">Se connecter</a>
        </div>
    ]
]

  Des utilisateurs m'appellent pour me signaler qu'après une déconnexion,
le champ 'login' du formulaire ne contient plus leur identifiant, mais
l'identifiant d'un autre utilisateur (qui ne s'est jamais connecté chez
eux).

  La seule chose étrange que je fais de temps en temps est ceci :

  suivre_invalideur("id='auteur/".$id_auteur."'");

mais je ne vois pas bien le rapport avec ce qui charge par défaut le
champ var_login dans login.php.

  Bien cordialement,

  JB

2

Hop,

3

Bruno Bergot a écrit :

Hop,

Des utilisateurs m&#39;appellent pour me signaler qu&#39;après une

déconnexion,
le champ 'login' du formulaire ne contient plus leur identifiant, mais
l'identifiant d'un autre utilisateur (qui ne s'est jamais connecté chez
eux).

Ton formulaire login ne serait pas dans un squelette appelé par un
#INCLURE (statique) au lieu de <INCLURE> (dynamique) ?

  Non, il est bien appelé par un <INCLURE>...

Extrait de auto/squelette_multiflex_officiel/v0.9.2/inc-colonne.html:

[(#REM) Connexion ]
[(#ENV{mfx_colonne_div}|=={oui}|oui)
    <INCLURE{fond=noisettes/login/inc/login}{env}>
]

  En revanche, je viens de m'apercevoir que dans le plugin Multiflex,
inc-colonne.html est appelé avec un #INCLURE. Je suppose qu'en utilisant
un <INCLURE> à la place, ça fonctionnera mieux. Tests en cours.

  Bien cordialement,

  JB

4

J'ai vérifié que tout était appelé par des balises <INCLURE> au lieu de
#INCLURE, le résultat est le même... Et ça reste pour moi un mystère.

5

Ça ne doit pas non plus être appelé dans un <modele|...> ou un #MODELE{...}

Et d'ailleurs ce serait bien que SPIP détecte et signale voire interdise ces situations.
JL

6

JLuc a écrit :

J&#39;ai vérifié que tout était appelé par des balises &lt;INCLURE&gt; au

lieu de
#INCLURE, le résultat est le même... Et ça reste pour moi un mystère.

 J&#39;ai vérifié que tout était appelé par des balises &lt;INCLURE&gt; au

lieu de

#INCLURE, le résultat est le même... Et ça reste pour moi un mystère.

Ça ne doit pas non plus être appelé dans un <modele|...> ou un #MODELE{...}

  Ça n'est pas appelé dans un modèle non plus. Je viens de vérifier, le
formulaire de login est appelé d'une cascade de <INCLURE>. Il n'y a
aucune balise #INCLURE entre Spip et le formulaire en question.

  Le problème est que je n'arrive pas à reproduire le phénomène depuis ma
machine de dev (NetBSD/Seamonkey) et que le problème semble survenir
fréquemment sous Windows 10/Firefox. Je ne vois pourtant pas pourquoi ça
aurait un rapport avec l'OS du client.

  Bien cordialement,

  JB