if ((lire_meta("mailing_list_manager") == $connect_id_auteur)
OR ($connect_statut == '0minirezo'))
{
if ($show_list) { @header("Content-Type: text/plain");
Heu, dis.... la mailing-list va utiliser l'authentification SPIP ?
FIND_IN_SET($show_list,auteurs.abonne)
Vaut mieux une table spip_listes_auteurs pour gérer le truc proprement.
function get_listes($statut_auteur) {
static $res;
if (!$res)
$res = spip_query ("SELECT * FROM spip_listes WHERE >
statut='publie' AND FIND_IN_SET('$statut_auteur', droits)");
return ($res);
}
Beurk...
while ($row = spip_fetch_array($res))
if (email_valide($row['email'])) {
$nom = $row['nom']; // a sanitizer !
$passliste = $row['abonne_pass']; // idem !
On ne devrait pas stocker de pass extérieur à SPIP. SPIP est censé être
"trusted" par le gestionnaire de listes, non ? Ca fait un pass en clair
(!) dans la base, qui en plus ne rentre en rien dans les données SPIP et
pollue la table pour rien ;-))
Sur le fond, le principe du polling, je trouve ça toujours aussi pourri,
la logique voudrait que ce soit SPIP qui contacte le gestionnaire de
listes et pas l'inverse....
Explications : tout ça repose sur une idée fausse (que les "groupes" ne sont
que des listes de diffusion et ne servent à rien d'autre) et sur une
interface d'inscription/désabonnement dans la page "messagerie" des auteurs.
Je suis content de l'interface... pas du reste. Et comme je n'ai pas le
temps de coder en ce moment, je préférais balancer l'interface pour ceusses
qui ça intéresserait de jouer avec. Mais je répète : ne pas utiliser ce
machin en production !
%%%%%
Heu, dis.... la mailing-list va utiliser l'authentification SPIP ?
Oui, c'était ça l'idée au départ. Mais on peut passer par un squelette ou
par un script ad hoc.
> FIND_IN_SET($show_list,auteurs.abonne)
Vaut mieux une table spip_listes_auteurs pour gérer le truc proprement.
Ouaips, pourquoi pas.
> function get_listes($statut_auteur) {
Beurk...
C'était pour éviter une surcharge. Pas glop ?
> $passliste = $row['abonne_pass']; // idem !
On ne devrait pas stocker de pass extérieur à SPIP.
Ouaips, aussi. L'idée était de fournir clés en main un mot de passe stable
et unique au gestionnaire de liste, car si on fait des mises à jour de
listes le gestionnaire a tendance à mettre des mots de passe aléatoires...
qui changent donc à chaque coup de polling....
Explications : tout ça repose sur une idée fausse (que les "groupes" ne sont
que des listes de diffusion et ne servent à rien d'autre)
Heu, non, là je suis d'accord : ça ne sert qu'à ça... Si on commence à
gérer des "groupes" d'utilisateurs sous SPIP, on n'est pas rendus...
(et celui qui veut absolument cette fonctionnalité peut contribuer le
code avec l'interface chiadée qui va avec ;-))
Je suis content de l'interface... pas du reste.
Sorry, c'est juste ce que je n'ai pas regardé...
Ouaips, aussi. L'idée était de fournir clés en main un mot de passe stable
et unique au gestionnaire de liste, car si on fait des mises à jour de
listes le gestionnaire a tendance à mettre des mots de passe aléatoires...
qui changent donc à chaque coup de polling....
Sympa réinitialise le pass pour des auteurs déjà inscrits ? C'est plutôt
un bug Sympa, non ?
Sympa réinitialise le pass pour des auteurs déjà inscrits ? C'est plutôt
un bug Sympa, non ?
Comment fais-tu depuis spip pour donner le mot de passe sympa à ton
utilisateur, si tu ne le fixes pas toi-même ? Ca est la question que je me
suis posée. Mais il vaut mieux se débarrasser de cette complication inutile,
tu as raison.
