#LOGIN_PUBLIC fait une boucle de rediction infinie !

fabs

Janvier 2009

Bonjour,
j’essaye d’installer un accès privilégié pour certains visiteurs dans la partie public du site.
Dès que j’insère LOGIN_PUBLIC dans mon squelette, Firefox me renvoi une erreur de boucle de redirection infinie.

Je suis avec un SPIP 2.0.3 tout frais
J’ai pourtant créé un article avec forum sur abonnement et activé l’inscription automatique.

J’ai certainement du oublié quelque chose... mais je n’arrive vraiment pas à déterminer quoi.

Pouvez-vous m’aider ?

Clore ce fil Résolu

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

denisb

Janvier 2009

quelle est donc ta méthode pour créer cet accès privilégié ?
comment utilises-tu la balise #LOGIN_PUBLIC ?
Indiquez l’intérêt que vous portez à cette réponse

0

fabs

Janvier 2009

Ma métode,
un identifiant, un mot de passe à entrer dans un cadre sur certaines page du site pour identifier l’utilisateur.
Une fois identifié, certaines pages contiennent des éléments supplémentaires.

Si j’ai bien compris, avec SPIP, on peut utiliser la table auteur pour des identification au niveau du site public ?

Mon problème est qu’avec un squelette presque vide, le simple ajout de #LOGIN_PUBLIC, fasse l’erreur "boucle de redirection infinie" générée par firefox.

Alors que je m’attendais à voir apparaitre le formulaire de connexion par defaut de SPIP.
Indiquez l’intérêt que vous portez à cette réponse

0

denisb

Janvier 2009

oui oui. normalement le formulaire apparaît.
as-tu essayé avec un autre navigateur ?
ou une url où l’on pourrait tester (juste une page test.html -copie de sommaire par exemple- appelable par ?page=test)
parce que j’ai beau triturer, à part des avertissements js dûs à jquery, tout fonctionne...
Indiquez l’intérêt que vous portez à cette réponse

0
Fabs

Janvier 2009
Bonjour,

j’ai un peu progressé,

J’ai pu affiché le formulaire en me battant avec le cache et la déconnexion.
J’entre alors des identifiants valides pour SPIP. Il me connect bien, mais fait la même erreur dans firefox.
(l’erreur semble donc générée lorsqu’il y a affichage du formulaire et que l’on est connecté)
J’ai donc protégé mon formulaire avec :
<?php if (!$auteur_session) { ?> #LOGIN_PUBLIC <?php } else { ?> Ok <?php }?>
Mais cela ne change rien.

J’ai donc suivi ton conseil et utilisé Opera,

effectivement, lui m’affiche un erreur plus précise :

HTTP 302 :

Il plaque ce code html à l’endroit du formulaire :
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html lang='fr' dir='ltr'> <head> <title>HTTP 302</title> </head> <body> <h1>HTTP 302</h1> <a href="spip.php?page=pole&id_rubrique=7">Si votre navigateur n'est pas redirigé, cliquez ici pour continuer.</a></body></html>
Et coupe la suite du code de la page.

Enfin, pour terminé, et peut-être le plus important, la cause viens effectivement de ma configuration, en utilisant un spip tout neuf, san squelette particulié, l’erreur ne se produit pas.

Merci, si vous avez des pistes pour éclairé ceci ?
Indiquez l’intérêt que vous portez à cette réponse

0

Fabs

Janvier 2009

J’ai trouvé la source,
l’URI de la page contenant le formulaire est du genre :

spip.php ?page=mapage&id_rubrique=2

Si j’enlève le id_rubrique, cela fonctionne.
Le #LOGIN_PUBLIC ne dépend bien sur pas de la présence de id_rubrique.
En faite, peu import le paramètre, son nom ou sa valeur.

Quelqu’un sait-il pourquoi, est-ce un bug de spip ?

Merci
Indiquez l’intérêt que vous portez à cette réponse

0

manu

Mars 2009

As-tu trouvé la réponse à ton soucis ? J’ai un peu le même avec SPIP2.03 et 2.05 dès que j’ai dans l’URL un passage d’argument spip.php ?.......&ad_machin=truc

C’est quoi le mystère ?
Indiquez l’intérêt que vous portez à cette réponse

0

soon7

Juillet 2009

Hello,

après plusieurs tests, j’ai la sensation que ca fait ce souci lorsque vous etes loggué en admin soit dans le formulaire public, ou vous etes loggués dans le écrire.

Bref dans les 2 cas spip a déposé un cooike sur votre machine, et c’est la présence de ce cookie + #LOGIN_PUBLIC + les autres varaibles passées qui lui font péter les plombs.

Donc lors de vos tests pour la partie public, effacez vos cookies avant de faire quoi que ce soit.
Pour éviter de le faire, et davoir à se relloguer à chaque fois en admin pour faire une modif, puis se délogguez et vider ses cookies pour tester laffichge public, ce que je fais moi c’est que j’utilise 2 navigateurs distincts.
Genre par exemple j’ouvre un IE dans lequel je suis loggué dans le écrire et je fais mes modifs, je vide le cache etc, et un firefox ou je teste le site public, en me logguant en tant que visiteur.
Ainsi le cookie admin est dans ie et firefox je suis un simple visiteur.

N’hésitez pas à tester aussi chez vous parce que ce sont des hypothèses à vérifier.
Indiquez l’intérêt que vous portez à cette réponse

0

fabs

Juillet 2009

Bonjour,

merci pour vos réponses à ce sujet, je n’est malheureusement jamais répondu à ce post depuis que ca marche chez moi. (bou pas bien,.. mal...)

Le problème est que je ne me souviens plus vraiment comment j’ai fais pour que cela fonctionne.
Mais il me semble que je suis simplement resté sur la configuration qui marchais. Cela fonctionne toujours avec la 2.0.8

Dans la config de spip, j’ai simplement coché "Enregistrement obligatoire (les utilisateurs doivent s’abonner en fournissant leur adresse e-mail avant de pouvoir poster des contributions)." dans interactivité.

(je n’ai activé aucun forum sur aucun article ou rubrique)
Indiquez l’intérêt que vous portez à cette réponse

0
mperraud

Juillet 2009
Environnement : SPIP 2.0.3, et soit site remote hébergé par phpnux, soit site local (wampserver windows Vista ou xp sp3).

Pour rendre le site temporairement fermé, accessible à une liste admin, auteurs, visiteurs préétablie, j’avais « inventé » le moyen suivant :
<div id="login2" style="display:none;height:auto;"> <B_articles> {... Traitement articles avec BOUCLE(ARTICLES) ...} </B_articles>  </div> <div id="login" style="display:block;"> [ (#LOGIN_PUBLIC) ] [ (#SESSION{statut}|=={0minirezo}|oui) [ (#INCLURE{fond=inc-nodisplay_sommaire}) ] ] [ (#SESSION{statut}|=={1comite}|oui) [ (#INCLURE{fond=inc-nodisplay_sommaire}) ] ] [ (#SESSION{statut}|=={6forum}|oui) [ (#INCLURE{fond=inc-nodisplay_sommaire})] ] </div>
Pas de problème majeur : si l’utilisateur est identifié comme membre des groupes admin, auteur ou visiteurs enregistrés, inc-nodisplay_sommaire s’exécute c’est-à-dire qu’une fonction javascript bascule le mode display des div login et login2, laissant apparaître le contenu du membre de page inclus dans la div login2.

Enfin, pas de problème avec toutes les pages du site en développement, sauf quand il y a appel à la page forum (répondre à : article, brève, etc.), car alors la contradiction avec #LOGIN_PUBLIC devient flagrante : boucle sur redirection.

en enlevant la div id="login" (qui contient la balise #LOGIN_PUBLIC) de la page, les réponses aux forums redeviennent normales.

Cependant, je ne suis pas entièrement satisfait de cette observation très empirique et je souhaite une explication plus circonstanciée.
Indiquez l’intérêt que vous portez à cette réponse

0

vwasteels

Juillet 2011

Salut !!

j’ai le même problème sur mon SPIP 2.1.10 :

/ ?page=evenement -> ça marche
/ ?page=evenement&qwerty=qwerty -> ça marche seulement si on est pas loggé (admin ou pas)

la page contient un formulaire #LOGIN_PUBLIC, le contenu complet des articles est masqués aux utilisateur non membres (cette logique n’affecte cependant pas la situation)

j’ai coché : Enregistrement obligatoire dans les config

mais rien n’y fait, j’ai vidé mes entrées dans le htaccess, sans résultats.

Est-ce que l’un d’entre vous saurait m’expliquer comment faire marcher le formulaire de login avec des paramètres dans l’url ?

Sachant que le fonctionnement voudrait que le formulaire ne s’affiche pas quand on est loggé

Merci !!!
Indiquez l’intérêt que vous portez à cette réponse

0

Novispip

Juillet 2011

Regardes si tu n’as pas deux fois la balise #LOGIN_PUBLIC dans la page chargée.

Regardes bien du côté de tes inclure ;)
Indiquez l’intérêt que vous portez à cette réponse

0

Suske

Juillet 2011

Il faut utiliser #LOGIN_PUBLIC dans un test, pour éviter de faire fabriquer le form alors qu’une session est déjà en cours :

[(#SESSION|non)#LOGIN_PUBLIC]
et le pendant (facultatif mais utile) pour la personne loguée (que vous êtes quand vous êtes connectés)
[[(#SESSION|oui)#URL_LOGOUT]

A part ça il faut aussi éviter de réveiller des fils de discussion de 2009... Je ferme celui-ci.

Cette discussion a été cloturée par un administrateur. Il n’est pas possible d’ajouter de nouveaux commentaires.