[spip-dev] forums publics sur abonnement

Coucou,

les forums publics sur abonnement sont une des premières applications des
sessions : les gens vont s'ientifier depuis l'espace public, se faire poser
un joli cookie de visiteur, et la fonction verifier_visiteur() donnera un
$auteur_session complet.

Du coup la nomenclature ($auteur_session) est mauvaise : déjà cet auteur
pouvait ne pas avoir de "session" à propremement parler dans data/
(connexion par auth http ou par auth php), mais maintenant il sera aussi
connecté par cookie hashé.

Question : on lui crée un fichier de session dans data/ ou on vérifie juste
avec un hash banal que le cookie est conforme au réglement ?

-- Fil

Question : on lui crée un fichier de session dans data/ ou on vérifie
juste avec un hash banal que le cookie est conforme au réglement ?

C'est quoi un "hash banal" ?
Ce serait mieux d'unifier....

@ Antoine Pitrou <antoine@rezo.net> :

>
> Question : on lui crée un fichier de session dans data/ ou on vérifie
> juste avec un hash banal que le cookie est conforme au réglement ?

C'est quoi un "hash banal" ?

Celui qui est actuellement dans le cookie d'auteur de forum par abo.

Ce serait mieux d'unifier....

OK, ça va générer pas mal de sessions dans data/ mais ça n'est pas gênant.

-- Fil

Celui qui est actuellement dans le cookie d'auteur de forum par abo.

Boah, il est laid ce code, j'avais fait ça n'importe comment.

les forums publics sur abonnement sont une des premières applications des
sessions : les gens vont s'ientifier depuis l'espace public, se faire poser
un joli cookie de visiteur, et la fonction verifier_visiteur() donnera un
$auteur_session complet.

Bon, hier j'étais enthousiaste mais il y a quelques questions à trancher.
Authentifier depuis l'espace public, est-ce que ça veut dire :

* avoir l'équivalent de la page ecrire/login.php3 à la racine du site

* ou juste un formulaire tout bête positionnable n'importe où ?

* ou encore une page type login.php3 mais en popup dans une fenêtre de
  petite taille ?

* ou encore un popup qui se déclenche quand on entre son login (mais pas le
  mot de passe) dans un mini-formulaire ?

La dernière hypothèse me semble la plus esthétique et la plus viable...

Ensuite, faut-il encore avoir un ecrire/login.php3 séparé de
l'authentification dans l'espace public, vu que, bon, l'auth, c'est
l'auth... ?

-- Fil

Ouh là, doucement...

Pour l'heure, l'identification sur le site public n'a qu'une seule utilité: les forums publics réglés en mode "abonnement". Pour le reste du site, ça ne sert à rien (la seule utilité étant de réaliser un traçage des visites selon les utilisateurs abonnés, ce qui est absolument hors de question avec SPIP - sauf à ce que SPIP obtienne un bug brother awards).

Donc, tant qu'il n'y a aucune autre utilité à l'indentification: le formulaire d'indentification, c'est celui qui est intégré aux forums sur abonnement.

Pour l'heure, l'identification sur le site public n'a qu'une seule
utilité: les forums publics réglés en mode "abonnement". Pour le
reste du site, ça ne sert à rien

Tu plaisantes ? Le but de toute l'opération (cookie de session posé dans
l'esapce public, etc.) est de pouvoir faire des parties consultables
uniquement par les visiteurs enregistrés et/ou des affichages différents
selon le statut du visiteur. De l'accès restreint : exactement ce qui se
passe avec les forums sur abonnement.

-- Fil

* avoir l'équivalent de la page ecrire/login.php3 à la racine du site

Je pense qu'à ce moment-là, c'est carrément un spip_login.php3 servant
à la fois pour le site public et l'espace privé qu'il faut mettre en
place.

> * ou juste un formulaire tout bête positionnable n'importe où ?

C'est ce qu'on fait pour l'instant, mais l'esthétique n'est pas toujours
réussie (formulaire en dur + mise en page personnalisée).

> * ou encore un popup qui se déclenche quand on entre son login (mais pas le
> mot de passe) dans un mini-formulaire ?

Je ne suis pas sûr d'avoir compris cette proposition-là :wink:

Pour moi le choix est entre les deux premiers...

Non, je ne plaisante pas. Le problème immédiat, c'est que les forums sur abonnement ne fonctionnent plus correctement. Et pour ça, l'interface est déjà prête, puisqu'elle existait déjà avant; le tout c'est qu'elle refonctionne correctement.

Et, non, ça n'est pas vraiment de l'accès restreint: les forums sont gérés de manière entièrement dynamique, donc ça n'est rigoureusement pas la même technique que le reste du site.

Sur l'accès restreint:

- Bon, en général, c'est une bonne grosse connerie: ça ne sert à rien. Des sites privés à accès public, c'est une chimère légale, ou un moyen de se faire chier. Ceux qui réclament ça, généralement, vont faire une bonne niaiserie derrière (en croyant que le fait de filer un mot de passe à des gens qu'ils ne sélectionnent pas les mets à l'abri des lois sur l'expression publique). Les cas où c'est utile sont extrêmement rares (j'en ai jamais vu).

- Avec les Nukeries, c'est un enfer. Sur Boomtchak, mon Mozilla m'interpelle à chaque page pour savoir si je veux m'indentifier avec le mot de passe qu'il a enregistré. Et comme je ne veux pas, j'ai droit au truc à chaque page successive.

- Quelles sont les fonctionnalités prévues liées à l'identification sur le site public?
- Comment ces fonctionnalités seront-elles intégrées au système de cache et au principe des boucles?

- Comment gérer les accès publics dans l'espace privé? Comment on indique qu'un utilisateur a accès à tel truc, comment on affiche ou pas la liste des rubriques/articles accessibles ou non sur le site privé? Comment, dans l'espace public, on traite les boucles (on n'affiche rien quand pas identifié, ou bien, ce qui est plus élégant, on affichage les titres des articles privés pour montrer ce qu'on manque mais on ne donne pas accès aux articles, et dans ce cas comment on fait dans les boucles?).

ARNO*

ça ne sert à rien.

http://MondeDiplo.com/ est sous spip, avec un contrôle d'accès qui fait
appel à une base de données externe. Ca me va, mais c'est moins
transportable-sauvegardable-réinstallable ailleurs qu'un spip.

Des sites privés à accès public, c'est une chimère légale, ou

tu es trop pris par les questions de droit d'auteur : il y a des tas de
raisons de vouloir que les visiteurs se logent. Album familial, notamment,
comme modèle de tous les machins associatifs.

- Avec les Nukeries, c'est un enfer. Sur Boomtchak, mon Mozilla

Je ne sais pas de quoi tu parles.

- Quelles sont les fonctionnalités prévues liées à l'identification
sur le site public?
- Comment ces fonctionnalités seront-elles intégrées au système de
cache et au principe des boucles?

L'idée est la suivante : chaque partie dépendant du client doit se trouver
dans un include (quand spip gérera les include) dont le $delai = 0. C'est
exactement la même idée pour la gestion du panier de la ménagère et autres
trucs rigolos suggérés sur la liste.

- Comment gérer les accès publics dans l'espace privé?

Pas compris la question

Comment on indique qu'un utilisateur a accès à tel truc, comment on
affiche ou pas la liste des rubriques/articles accessibles ou non sur le
site privé?

Ca fait partie de la structure du site, donc c'est dans les squelettes, pas
dans l'espace privé. Spip ne donnera que des outils pour faire des trucs sur
mesure, et les gens s'échangeront dess squelettes qui marchent.

Exemples : Nicolas veut un mot-clé "accès restreint", Jacques veut que les
archives de plus de 100 jours soient en accès restreint, et Paola veut
afficher les titres des "articles du jour" mais ne laisser accès libre
qu'aux archives. Quant à Sabine, elle estime qu'il lui suffit d'un secteur
restreint.

Comment, dans l'espace public, on traite les boucles (on n'affiche rien
quand pas identifié, ou bien, ce qui est plus élégant, on affichage les
titres des articles privés pour montrer ce qu'on manque mais on ne donne
pas accès aux articles, et dans ce cas comment on fait dans les boucles?).

Avec des include de $delai=0 ou des tests conditionnels, selon les cas. Il
faut voir...

(Fil: ça c'était le début de ton mail, mais ma réponse vient en

conclusion du mien) Non, je ne plaisante pas. Le problème immédiat, c'est
que les forums sur abonnement ne fonctionnent plus correctement. Et pour
ça, l'interface est déjà prête, puisqu'elle existait déjà avant; le tout
c'est qu'elle refonctionne correctement.

A mon avis, plutôt que d'aller corriger un bout de truc en montant une usine
à gaz pour récupérer les rédacteurs - à condition qu'ils se soient logés -,
il vaut mieux faire un bon gros truc de fond, sur des bases solides, qui
soit programmé avec moins de code et de cas particuliers, et qui nous
simplifiera la vie plus tard. Il y a juste une petite question d'interface
si on veut que ce soit joli.

-- Fil

A mon avis, plutôt que d'aller corriger un bout de truc en montant une usine
à gaz pour récupérer les rédacteurs - à condition qu'ils se soient logés -,

Hé ho, rigolo plein de poils! :slight_smile:
J'ai seulement signalé que les forums sur abonnement ne fonctionnaient plus, que j'avais mis une rustine (dont j'ai bien dit que c'était pas bon), et qu'il faudrait réparer. J'ai pas demandé une usine à gaz... Y'avait un truc qui marchait, qui ne marche plus, donc faut corriger, c'est tout.

il vaut mieux faire un bon gros truc de fond, sur des bases solides, qui
soit programmé avec moins de code et de cas particuliers, et qui nous
simplifiera la vie plus tard. Il y a juste une petite question d'interface
si on veut que ce soit joli.

Bon, ben je suppose que tu nous feras la doc expliquant à Mari-Jo comment son site des camps de scout, elle peut en réserver l'accès aux parents d'élèves sans devenir dingue. Je te fais confiance.

Pour l'interface, ben il est très bien le pavé des formulaires sur abonnement. Graphiquement suffit de faire pareil.
Pour l'insertion, y'a qu'à faire un #FORMULAIRE_IDENTIFICATION, qui gère le tout.

Si t'as du mal avec l'interface, tu t'embêtes pas: tu fais le truc qui fonctionne et je repasserai derrière si nécessaire.

ARNO*

'lo,

> L'idée est la suivante : chaque partie dépendant du client doit se trouver
> dans un include (quand spip gérera les include) dont le $delai = 0. C'est

Heu, si on s'est fait chier à programmer des sessions sans accès à la base,
c'est pas pour que l'accès restreint désactive le cache !

Bon, ben je suppose que tu nous feras la doc expliquant à Mari-Jo
comment son site des camps de scout, elle peut en réserver l'accès
aux parents d'élèves sans devenir dingue. Je te fais confiance.

Commençons par fournir un système de login et par l'utiliser sur les forums
sur abo, hein !

tu fais le truc qui fonctionne

Création d'auteur 6forum à la demande, login en session (et md5 jajascript)
pour tout le monde, c'est fait, dans deux fichiers que je ne vais pas
commiter, mais que tu peux trouver là :
    http://rezo.net/~fil/spip/spip-sessions/
et tester ici :
    http://rezo.net/~fil/spip/toto.php

(toto.php ne fait que vérifier la présence ou non d'une session et appelle
si besoin le popup d'identification ; je ne sais pas comment le popup, quand
il se ferme parce qu'il est content de l'identification, peut envoyer un
"reload" à la page qui l'avait appelé).

et je repasserai derrière si nécessaire.

Pour utiliser les sessions à l'intérieur d'inc-forum.php3, c'est sûrement
facile à condition de rentrer dans la logique de ce bout de code, avec ses
hash_action, ses mots-clés etc. Et là, c'est trop bordélique pour moi...
M'enfin, il suffit de regarder si une session existe (si oui, c'est qu'elle a
été vérifiée par inc-public (global $auteur_session est vide sinon).

On peut alors utiliser les contenus de $auteur_session['statut'], ['nom'],
['email'], ['id_auteur'] pour remplir/vérifier les infos nécessaires.

-- Fil

    http://rezo.net/~fil/spip/spip-sessions/

Comme on voit, le code de login.php ressemble très fort à celui de
ecrire/login.php3 ... si on avance dans cette direction, il faudra réunir
les deux codes dans un inc_login centralisé. Là c'était pour aller vite.

-- Fil

Fil wrote:
> Exemples : Nicolas veut un mot-clé "accès restreint", Jacques veut que les
> archives de plus de 100 jours soient en accès restreint, et Paola veut
> afficher les titres des "articles du jour" mais ne laisser accès libre
> qu'aux archives...

Dans ce cas, pour le répertoire IMG/ contenant toutes les images et
documents asociés aux rubriques/articles, il faut au minimun placer un
fichier "index.htm" vide (Pour éviter l'accès direct aux documents)

Fabrice

PS
Cette histoire de login pour l'espace public,
c'est très intéressant...

Même si l'accès restreint est conditionné aux squelettes, et non aux articles/rubriques eux même.

Hello,

avoir l'équivalent de la page ecrire/login.php3 à la racine du site

Je pense qu'à ce moment-là, c'est carrément un spip_login.php3
servant à la fois pour le site public et l'espace privé qu'il faut
mettre en place.

Ouaip, pourquoi pas, mais je n'aime pas l'effet tunnel des multiples
pages pour une fonction toute simple (et petite visuellement).

ou juste un formulaire tout bête positionnable n'importe où ?

C'est ce qu'on fait pour l'instant, mais l'esthétique n'est pas
toujours réussie (formulaire en dur + mise en page personnalisée).

C'est à mon avis la meilleure solution, mais c'est clair qu'il faut
qu'il soit personnalisable, par exemple qu'on puisse le faire soi-même
à la main, comme pour la recherche entre autre ...

ou encore un popup qui se déclenche quand on entre son login (mais
pas le mot de passe) dans un mini-formulaire ?

Beurk, je n'aime pas les popups (sauf pour la gestion des documents
attachés) ... :wink:

-Nicolas

je ne sais pas comment le popup, quand il se ferme parce qu'il est
content de l'identification, peut envoyer un "reload" à la page qui
l'avait appelé

En gros, c'est ça en jajascript :

window.opener.location.href=window.opener.location.url

Je ne suis plus vraiment sûr de l'ordre href et url, mais c'est à peu
près ça ...

-Nicolas

Avec les Nukeries, c'est un enfer. Sur Boomtchak, mon Mozilla
m'interpelle à chaque page pour savoir si je veux m'indentifier avec
le mot de passe qu'il a enregistré. Et comme je ne veux pas, j'ai
droit au truc à chaque page successive.

Il suffit que tu dises à ton Moz de ne jamais stocker de mot de passe
pour ce site, c'est tout.

-Nicolas

Fil wrote:
  > Exemples : Nicolas veut un mot-clé "accès restreint",
> Jacques veut que les archives (...) et Paola veut
  > afficher les titres des "articles du jour" mais ne
  > laisser accès libre qu'aux archives...

Dans ce cas, pour le répertoire IMG/ contenant toutes les images et
documents asociés aux rubriques/articles, il faut au minimun placer un
fichier "index.htm" vide (Pour éviter l'accès direct aux documents)

Fabrice

PS
Cette histoire de login pour l'espace public,
c'est très intéressant...

Même si l'accès restreint est conditionné aux squelettes, et non aux
articles/rubriques eux même.

Bonsoir,

Dans un message datant d'une quinzaine,
il a été évoqué la réalisation d'une documentation
sur les filtres existant en standard.

C'est tjs d'actualité ?
Quelqu'un à t-il commencé ?

Autrement, je veux bien m'y coller.
En fait c'est surtout pour m'aider à apprendre ces filtres...

Un résumé des filtres comme celui des typos semble être parfait.

Voila / a+
Fabrice

PS
Le moteur de recherche ne fonctionne pas sur les archives de la liste.