Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

[Stéphane MUSSET <address@concealed>]

Bonjour Luc,

Oui en effet je parlais bien de ce fichier et uniquement sans aucun autre changement. (et en effet à part éventuellement un petit restart des services).

Je n'avais pas constaté d'effet sur le navigateur (même si je suis le seul à utiliser l'admin sympa en pratique vu que le reste se fait via le webservice et sur un serveur de liste associatif avec assez peu de listes, une 20aine).

Le problème que tu rencontres est donc peut-être légèrement différent.

Ce qui est certain c'est que je l'ai fait sur plusieurs versions sans soucis (en étant certes un peu inquiet de ma manip' mais vu que nous étions un peu bloqué.

Et je viens du coup d'aller vérifier la version et en fait ce serait même carrément un SOAP.pm d'une 6.1.16 (si j'en crois les renommages que j'ai conservé). Pardon pour ce numéro de version assez proche qui a fait dérailler ma mémoire. Je peux te l'envoyer en mail direct si tu veux (je ne sais pas s'il est possible de vérifier facilement la version d'un fichier isolé des sources SYMPA).

J'ai tout de même un gros doute car j'ai un fichier SOAP.pm_6.1.16 de côté de 65309 octets et un SOAP.pm_6.2.32 aussi de 65309 et dont le diff ne donne pas de différences (contrairement à un diff sur un SOAP.pm_6.2.23). Vu que cela de quelques mois, un peu dans l'urgence et un peu empirique, une fois que ça a fonctionné je n'ai pas trop insisté.

Stéphane

Le 08/11/2018 à 16:48, Luc VEILLON (via sympa-fr Mailing List) a écrit :

Bonjour Stéphane (via la liste)

Tu parlais bien de SOAP.pm et uniquement lui ? Sans aucun changement par ailleurs si ce n'est redémarrage sympa et httpd ?

J'ai testé avec le fichier de la 6.2.12 (qui marchait dans notre environnement) et ça ne change rien.

Il y a des effets de bords avec erreur 500 sur le navigateur, du coup, j'ai élargi à

./Sympa/SOAP.pm.6.2.12

./Sympa/SOAP/Transport.pm.6.2.12

./sympa_soap_server-wrapper.fcgi.6.2.12

sans effet.

Je viens de repasser en 6.2.22 puis de modifier seulement en utilisant

./Sympa/SOAP.pm.6.2.16

sans effet (mais sans erreur 500).

Je suis sec !

(mais j'envisage migration sur version ultérieure...)

Le 04/11/2018 à 12:16, Smrhp (via sympa-fr Mailing List) a écrit :

Bonjour,

Je pense que tu es tombé sur le bug que j'ai eu sur cette version 6.2.22 en décembre 2017. Je m'en étais sorti en remplaçant uniquement le fichier Soap.pm par celui de la 6.2.16 (de mémoire je crois) et ça a bien fonctionné.

Désormais depuis une 6.2.3x, le problème semble résolu car je n'ai plus besoin de remplacer ce fichier pour que cela fonctionne. Mais j'ai quelques versions de retards (je suis en 6.2.32 sur le serveur concerné par cet usage).

Cdlt,
Stéphane

Le 31/10/2018 à 11:53, Luc VEILLON (via sympa-fr Mailing List) a écrit :

Bonjour,

je profite de cet échange pour signaler un souci qui est apparu entre 6.2.12 et 6.2.22

=> en 6.2.12, un de nos prestataires propose l'abonnement à une liste que nous gérons via un formulaire utilisant l'api SOAP : les candidats qui déposent leur demande sur ce formulaire sont bien abonnés

=> en 6.2.22, effet immédiat : les candidats ne sont plus abonnés

Les logs de sympa 6.2.22 :

2018-10-31T11:15:11.080981+01:00 pr-ari-sympa11 sympasoap[1348]: notice Sympa::SOAP::authenticateAndRun(login_autorise@domaine, 01234key, amI, address@concealed,subscriber,candidat.abonne@sondomaine)
2018-10-31T11:15:11.084635+01:00 pr-ari-sympa11 sympasoap[1348]: notice Sympa::SOAP::amI(address@concealed, subscriber, candidat.abonne@sondomaine)
2018-10-31T11:15:11.099532+01:00 pr-ari-sympa11 sympasoap[1348]: notice Sympa::SOAP::authenticateAndRun(login_autorise@domaine, 01234key, add, address@concealed,candidat.abonne@sondomaine)
2018-10-31T11:15:11.103003+01:00 pr-ari-sympa11 sympasoap[1348]: info Sympa::SOAP::add(list = *address@concealed@ldif.education.gouv.fr*, email = candidat.abonne@sondomaine, *quiet = *) From login_autorise@domaine via proxy application
2018-10-31T11:15:11.105149+01:00 pr-ari-sympa11 sympasoap[1348]: notice Sympa::Spindle::ProcessRequest::_twist() Processing Sympa::Request <action="add;address@concealed;email=candidat.abonne@sondomaine>
et juste après, peut être en relation :

2018-10-31T11:15:12.184997+01:00 pr-ari-sympa11.ariel.in.phm.education.gouv.fr sympa_msg[32699]: notice Sympa::Spindle::ProcessIncoming::_twist() Processing Sympa::Message <address@concealed>; envelope_sender=; address@concealed; address@concealed
2018-10-31T11:15:12.217954+01:00 pr-ari-sympa11.ariel.in.phm.education.gouv.fr sympa_msg[32699]: err main::#243 > Sympa::Spindle::spin#80 > Sympa::Spindle::ProcessIncoming::_twist#237 List sympa does not exist

=> le paramètre "address@concealed@ldif.education.gouv.fr" semble inquiétant mais il y avait le même log en 6.2.12 quand ça fonctionnait, et le développeur a fait un test en supprimant le domaine de la liste (puisqu'il s'adresse à une entrée SOAP en FQDN, donc avec notion implicite du robot) : ça n'a rien amélioré.

=> en 6.2.22 l'ajout manuel d'abonné ajoute un écran de validation supplémentaire, pour valider la valeur de quiet. Le formulaire ne valorise pas quiet, et ne prévoit rien à ce sujet.

=> un abonnement manuel effectué sur l'IHM sympa de ce robot, en copiant/collant liste, robot et email du candidat à l'abonnement,  fonctionne parfaitement : les paramètres ne semblent pas présenter d'erreur typographique


Ce que reçoit le client

"L'adresse de la liste sympa saisie n'est pas valide. "
et dans la réponse navigateur : email_liste_sympa_invalide

Les traces visibles dans les journaux de l'application (même erreur mais un autre jour que les logs ci-dessus) :

Wed Oct 24 2018 11:41:48 info - url : http://www.education.gouv.fr/form...
Wed Oct 24 2018 11:41:48 info - email liste sympa : address@concealed
Wed Oct 24 2018 11:41:48 error - bug in logic. Ask developer at /appli/sympa/sympaV6.2.22/sympa/bin/Sympa/Spindle/AuthorizeRequest.pm line 67.

Ce qui correspond à

    # Check if required context (known list or robot) is given.
    if (defined $request->handler->context_class
        and $request->handler->context_class ne ref $request->{context}) {
        $request->{error} = 'unknown_list';
        return ['Sympa::Spindle::DispatchRequest'];
    }
    my $that = $request->{context};

    my $context = $self->{scenario_context}
        or die 'bug in logic. Ask developer';

On tourne autour d'un pb de liste ou de robot mal défini, mais je ne vois pas où se situe la difficulté...
Cordialement


Le 30/10/2018 à 13:25, David Verdin a écrit :

Bonjour,

Le meilleur moyen est d'utiliser l'API SOAP. I faut positionner une trusted_application et envoyer des commandes subscribe à Sympa avec un client SOAP.

Tous les détails ici : https://sympa-community.github.io/manual/customize/soap-api.html

Bonne journée !

David


On 30/10/2018 13:16, Martin wrote:

Bonjour,

Nous souhaitons pouvoir déclencher l'inscription d'un utilisateur à
partir de son adresse mail via un formulaire externe.

L'effet devra être le même que si il soumettait lui-même son adresse
email depuis l'interface web sous /subscribe/<nomdelalist> - sous
entendu, suivant la config de la liste il reçoit les mails de
validation/confirmation et selon les scénarios les gestionnaires de
listes reçoivent les notifications configurées.

Quelle est la façon la plus élégante d'y parvenir ? Via l'API ? en
faisant un POST sur le formulaire web sympa ?

Merci d'avance,

-- 

Luc Veillon
Responsable HUB de fédération
Responsable Messagerie
DSI/Pôle IH2M

address@concealed
T 02 38 79 45 20
M 06 24 84 13 30

Rectorat de l'académie d'Orléans-Tours
21 rue Saint-Étienne
45043 Orléans Cedex 1
www.ac-orleans-tours.fr

-- 

Luc Veillon
Responsable HUB de fédération
Responsable Messagerie
DSI/Pôle IH2M

address@concealed
T 02 38 79 45 20
M 06 24 84 13 30

Rectorat de l'académie d'Orléans-Tours
21 rue Saint-Étienne
45043 Orléans Cedex 1
www.ac-orleans-tours.fr