j'utilise le module soappy pour dialoguer avec un serveur WebServices
(WS). Ce module fonctionne parfaitement ... sauf que le serveur WS
présente un particularité: il attend l'authentification dans les lignes
headers du dialogue http. Je précise que le traitement de
l'authentification est pris en charge par les services du WS , et non
par le serveur http derrière lequel sont invoqués les services en
question. J'ai résolu le problème en "patchant" temporairement les sources.
Question: Y a t il parmis vous qui aurait utilisé ce module ? merçi.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
m.banaouas
apparemment, c'est pas très passionnant comme question. Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet (soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
merci
apparemment, c'est pas très passionnant comme question.
Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet
(soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
apparemment, c'est pas très passionnant comme question. Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet (soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
merci
Amaury Forgeot d'Arc
apparemment, c'est pas très passionnant comme question. Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet (soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
Si si, c'est juste que je n'ai pas eu le temps récemment... Sur ce forum, il faut quelquefois attendre quelques jours !
-- Amaury
apparemment, c'est pas très passionnant comme question.
Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet
(soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
Si si, c'est juste que je n'ai pas eu le temps récemment...
Sur ce forum, il faut quelquefois attendre quelques jours !
apparemment, c'est pas très passionnant comme question. Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet (soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
Si si, c'est juste que je n'ai pas eu le temps récemment... Sur ce forum, il faut quelquefois attendre quelques jours !
-- Amaury
Olivier
Hello,
apparemment, c'est pas très passionnant comme question.
Juste histoire que tu te sentes moins seul ... ;o) J'ai utilisé soappy il y a deux/trois ans pour faire un serveur de cache de résultats de requêtes sql à l'usage d'une appli web qui ne gérait pas de persistence. Il n'y avait aucun besoin d'authentification, donc je ne peux pas vraiment te faire partager mon expérience.
Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet (soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
J'ai effectivemment l'impression que ça intéresse peu les pythonistes, qui sont très contents avec xmlrpc.
Olivier
Hello,
apparemment, c'est pas très passionnant comme question.
Juste histoire que tu te sentes moins seul ... ;o)
J'ai utilisé soappy il y a deux/trois ans pour faire un serveur de cache
de résultats de requêtes sql à l'usage d'une appli web qui ne gérait pas
de persistence.
Il n'y avait aucun besoin d'authentification, donc je ne peux pas
vraiment te faire partager mon expérience.
Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet
(soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
J'ai effectivemment l'impression que ça intéresse peu les pythonistes,
qui sont très contents avec xmlrpc.
apparemment, c'est pas très passionnant comme question.
Juste histoire que tu te sentes moins seul ... ;o) J'ai utilisé soappy il y a deux/trois ans pour faire un serveur de cache de résultats de requêtes sql à l'usage d'une appli web qui ne gérait pas de persistence. Il n'y avait aucun besoin d'authentification, donc je ne peux pas vraiment te faire partager mon expérience.
Est-ce parce qu'elle n'est pas bien posée ou bien parce que le sujet (soap, wsdl, ...) n'est pas abordé par les participants de ce forum ?
J'ai effectivemment l'impression que ça intéresse peu les pythonistes, qui sont très contents avec xmlrpc.
Olivier
Amaury Forgeot d'Arc
bonsoir à tous,
j'utilise le module soappy pour dialoguer avec un serveur WebServices (WS). Ce module fonctionne parfaitement ... sauf que le serveur WS présente un particularité: il attend l'authentification dans les lignes headers du dialogue http. Je précise que le traitement de l'authentification est pris en charge par les services du WS , et non par le serveur http derrière lequel sont invoqués les services en question. J'ai résolu le problème en "patchant" temporairement les sources.
Question: Y a t il parmis vous qui aurait utilisé ce module ? merçi.
Juste une idée : as-tu essayé avec une url de la forme : http://user:/...
En regardant le code source de soappy, il semble que ça ajoute le header suivant: Authorisation = Basic <user:password encodé avec base64>
Est-ce cela qui est désiré ?
-- Amaury
bonsoir à tous,
j'utilise le module soappy pour dialoguer avec un serveur WebServices
(WS). Ce module fonctionne parfaitement ... sauf que le serveur WS
présente un particularité: il attend l'authentification dans les lignes
headers du dialogue http. Je précise que le traitement de
l'authentification est pris en charge par les services du WS , et non
par le serveur http derrière lequel sont invoqués les services en
question. J'ai résolu le problème en "patchant" temporairement les sources.
Question: Y a t il parmis vous qui aurait utilisé ce module ? merçi.
Juste une idée :
as-tu essayé avec une url de la forme :
http://user:password@www.server.com/...
En regardant le code source de soappy, il semble que ça ajoute le header
suivant:
Authorisation = Basic <user:password encodé avec base64>
j'utilise le module soappy pour dialoguer avec un serveur WebServices (WS). Ce module fonctionne parfaitement ... sauf que le serveur WS présente un particularité: il attend l'authentification dans les lignes headers du dialogue http. Je précise que le traitement de l'authentification est pris en charge par les services du WS , et non par le serveur http derrière lequel sont invoqués les services en question. J'ai résolu le problème en "patchant" temporairement les sources.
Question: Y a t il parmis vous qui aurait utilisé ce module ? merçi.
Juste une idée : as-tu essayé avec une url de la forme : http://user:/...
En regardant le code source de soappy, il semble que ça ajoute le header suivant: Authorisation = Basic <user:password encodé avec base64>
Est-ce cela qui est désiré ?
-- Amaury
mbana
Ah! il y a du bruit , c'est bon signe...
plus sérieusement, je vais essayer de préciser le problème rencontré: dans le processus de dialogue avec un WebService (WS) via le module soappy, on peut distinguer deux phases majeures: 1- l'instanciation d'un objet proxy qui demande l'url du WS 2- l'invocation du service avec passage des arguments et récupération des résultats en retour; dit de cette façon, cela semble très simple; pourtant, pour avoir modestement exploré le wsdl, j'estime qu'il y a là un très gros travail d'encapsulation fait par le module soappy pour en arriver à cette apparente (et effective) simplicité.
mon problème se situe dans la phase d'authentification; en effet, je transmet user:password dans l'url lors de l'obtention de l'objet proxy du service. Mais j'ai constaté que ce user:password n'est pas retransmis à chaque échange http correspondant à la phase 2. Du coup, il y a échec d'authentification.
J'ai contacté les développeurs du service en question (soit dit en passant, c'est sous apache/tomcat/axis et l'implémentation est en java) qui m'ont confirmé que l'authentification n'est pas déléguée au serveur web mais bien traitée par le service lui même. Mon patch temporaite a consisté à "forcer" la retransmission du user:password dans les headers. Cela se passe dans le source client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas de retransmission du user:password fourni au départ, comme si le module ne le consignait nulle part et du coup il n'est pas trouvé par la suite.
J'ai même envoyé des mails aux mainteneurs du module mais c'est resté sans réponse.
merci bien pour vos réponses.
bonsoir à tous,
j'utilise le module soappy pour dialoguer avec un serveur WebServices (WS). Ce module fonctionne parfaitement ... sauf que le serveur WS présente un particularité: il attend l'authentification dans les lignes headers du dialogue http. Je précise que le traitement de l'authentification est pris en charge par les services du WS , et non par le serveur http derrière lequel sont invoqués les services en question. J'ai résolu le problème en "patchant" temporairement les sources.
Question: Y a t il parmis vous qui aurait utilisé ce module ? merçi.
Juste une idée : as-tu essayé avec une url de la forme : http://user:/...
En regardant le code source de soappy, il semble que ça ajoute le header suivant: Authorisation = Basic <user:password encodé avec base64>
Est-ce cela qui est désiré ?
Ah! il y a du bruit , c'est bon signe...
plus sérieusement, je vais essayer de préciser le problème rencontré:
dans le processus de dialogue avec un WebService (WS) via le module
soappy, on peut distinguer deux phases majeures:
1- l'instanciation d'un objet proxy qui demande l'url du WS
2- l'invocation du service avec passage des arguments et récupération
des résultats en retour; dit de cette façon, cela semble très simple;
pourtant, pour avoir modestement exploré le wsdl, j'estime qu'il y a là
un très gros travail d'encapsulation fait par le module soappy pour en
arriver à cette apparente (et effective) simplicité.
mon problème se situe dans la phase d'authentification; en effet, je
transmet user:password dans l'url lors de l'obtention de l'objet proxy
du service. Mais j'ai constaté que ce user:password n'est pas retransmis
à chaque échange http correspondant à la phase 2. Du coup, il y a
échec d'authentification.
J'ai contacté les développeurs du service en question (soit dit en
passant, c'est sous apache/tomcat/axis et l'implémentation est en java)
qui m'ont confirmé que l'authentification n'est pas déléguée au serveur
web mais bien traitée par le service lui même. Mon patch temporaite a
consisté à "forcer" la retransmission du user:password dans les headers.
Cela se passe dans le source client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas de
retransmission du user:password fourni au départ, comme si le module ne
le consignait nulle part et du coup il n'est pas trouvé par la suite.
J'ai même envoyé des mails aux mainteneurs du module mais c'est resté
sans réponse.
merci bien pour vos réponses.
bonsoir à tous,
j'utilise le module soappy pour dialoguer avec un serveur WebServices
(WS). Ce module fonctionne parfaitement ... sauf que le serveur WS
présente un particularité: il attend l'authentification dans les
lignes headers du dialogue http. Je précise que le traitement de
l'authentification est pris en charge par les services du WS , et non
par le serveur http derrière lequel sont invoqués les services en
question. J'ai résolu le problème en "patchant" temporairement les
sources.
Question: Y a t il parmis vous qui aurait utilisé ce module ? merçi.
Juste une idée :
as-tu essayé avec une url de la forme :
http://user:password@www.server.com/...
En regardant le code source de soappy, il semble que ça ajoute le header
suivant:
Authorisation = Basic <user:password encodé avec base64>
plus sérieusement, je vais essayer de préciser le problème rencontré: dans le processus de dialogue avec un WebService (WS) via le module soappy, on peut distinguer deux phases majeures: 1- l'instanciation d'un objet proxy qui demande l'url du WS 2- l'invocation du service avec passage des arguments et récupération des résultats en retour; dit de cette façon, cela semble très simple; pourtant, pour avoir modestement exploré le wsdl, j'estime qu'il y a là un très gros travail d'encapsulation fait par le module soappy pour en arriver à cette apparente (et effective) simplicité.
mon problème se situe dans la phase d'authentification; en effet, je transmet user:password dans l'url lors de l'obtention de l'objet proxy du service. Mais j'ai constaté que ce user:password n'est pas retransmis à chaque échange http correspondant à la phase 2. Du coup, il y a échec d'authentification.
J'ai contacté les développeurs du service en question (soit dit en passant, c'est sous apache/tomcat/axis et l'implémentation est en java) qui m'ont confirmé que l'authentification n'est pas déléguée au serveur web mais bien traitée par le service lui même. Mon patch temporaite a consisté à "forcer" la retransmission du user:password dans les headers. Cela se passe dans le source client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas de retransmission du user:password fourni au départ, comme si le module ne le consignait nulle part et du coup il n'est pas trouvé par la suite.
J'ai même envoyé des mails aux mainteneurs du module mais c'est resté sans réponse.
merci bien pour vos réponses.
bonsoir à tous,
j'utilise le module soappy pour dialoguer avec un serveur WebServices (WS). Ce module fonctionne parfaitement ... sauf que le serveur WS présente un particularité: il attend l'authentification dans les lignes headers du dialogue http. Je précise que le traitement de l'authentification est pris en charge par les services du WS , et non par le serveur http derrière lequel sont invoqués les services en question. J'ai résolu le problème en "patchant" temporairement les sources.
Question: Y a t il parmis vous qui aurait utilisé ce module ? merçi.
Juste une idée : as-tu essayé avec une url de la forme : http://user:/...
En regardant le code source de soappy, il semble que ça ajoute le header suivant: Authorisation = Basic <user:password encodé avec base64>
Est-ce cela qui est désiré ?
Amaury Forgeot d'Arc
Mon patch temporaite a consisté à "forcer" la retransmission du user:password dans les headers. Cela se passe dans le source client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas de retransmission du user:password fourni au départ, comme si le module ne le consignait nulle part et du coup il n'est pas trouvé par la suite.
Justement dans ce source client.py, classe HTTPTransport, methode call, as-tu regardé la valeur de addr.user ? Il me semble que c'est là que l'authentification doit être enregistrée. Et si la valeur reste vide, essaie de tracer les appels à SOAPAddress(), pour voir les adresses qui sont passées.
-- Amaury
Mon patch temporaite a
consisté à "forcer" la retransmission du user:password dans les headers.
Cela se passe dans le source client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas de
retransmission du user:password fourni au départ, comme si le module ne
le consignait nulle part et du coup il n'est pas trouvé par la suite.
Justement dans ce source client.py, classe HTTPTransport, methode call,
as-tu regardé la valeur de addr.user ? Il me semble que c'est là que
l'authentification doit être enregistrée.
Et si la valeur reste vide, essaie de tracer les appels à SOAPAddress(),
pour voir les adresses qui sont passées.
Mon patch temporaite a consisté à "forcer" la retransmission du user:password dans les headers. Cela se passe dans le source client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas de retransmission du user:password fourni au départ, comme si le module ne le consignait nulle part et du coup il n'est pas trouvé par la suite.
Justement dans ce source client.py, classe HTTPTransport, methode call, as-tu regardé la valeur de addr.user ? Il me semble que c'est là que l'authentification doit être enregistrée. Et si la valeur reste vide, essaie de tracer les appels à SOAPAddress(), pour voir les adresses qui sont passées.
-- Amaury
mbana
réponse: vide! c'est exactement là où le bat blesse! par défaut, les appels ne comportent pas d'authentification. Même en tracant le dialogue http, pas de trace (...) d'authentification (la fameuse ligne Autorization: ...). pour que ça fonctionne, j'ai dû "réinjecter" le user:password. Et ca fonctionne très bien depuis. mais je pense tout de même qu'il doit y avoir une facon plus "propre" pour y arriver.
Mon patch temporaite a consisté à "forcer" la retransmission du user:password dans les headers. Cela se passe dans le source client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas de retransmission du user:password fourni au départ, comme si le module ne le consignait nulle part et du coup il n'est pas trouvé par la suite.
Justement dans ce source client.py, classe HTTPTransport, methode call, as-tu regardé la valeur de addr.user ? Il me semble que c'est là que l'authentification doit être enregistrée. Et si la valeur reste vide, essaie de tracer les appels à SOAPAddress(), pour voir les adresses qui sont passées.
réponse: vide!
c'est exactement là où le bat blesse!
par défaut, les appels ne comportent pas d'authentification. Même en
tracant le dialogue http, pas de trace (...) d'authentification (la
fameuse ligne Autorization: ...).
pour que ça fonctionne, j'ai dû "réinjecter" le user:password. Et ca
fonctionne très bien depuis.
mais je pense tout de même qu'il doit y avoir une facon plus "propre"
pour y arriver.
Mon patch temporaite a consisté à "forcer" la retransmission du
user:password dans les headers. Cela se passe dans le source
client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas
de retransmission du user:password fourni au départ, comme si le
module ne le consignait nulle part et du coup il n'est pas trouvé par
la suite.
Justement dans ce source client.py, classe HTTPTransport, methode call,
as-tu regardé la valeur de addr.user ? Il me semble que c'est là que
l'authentification doit être enregistrée.
Et si la valeur reste vide, essaie de tracer les appels à SOAPAddress(),
pour voir les adresses qui sont passées.
réponse: vide! c'est exactement là où le bat blesse! par défaut, les appels ne comportent pas d'authentification. Même en tracant le dialogue http, pas de trace (...) d'authentification (la fameuse ligne Autorization: ...). pour que ça fonctionne, j'ai dû "réinjecter" le user:password. Et ca fonctionne très bien depuis. mais je pense tout de même qu'il doit y avoir une facon plus "propre" pour y arriver.
Mon patch temporaite a consisté à "forcer" la retransmission du user:password dans les headers. Cela se passe dans le source client.py, classe HTTPTransport, methode call.
Je pense que l'echec d'athentification vient du fait qu'il n'y a pas de retransmission du user:password fourni au départ, comme si le module ne le consignait nulle part et du coup il n'est pas trouvé par la suite.
Justement dans ce source client.py, classe HTTPTransport, methode call, as-tu regardé la valeur de addr.user ? Il me semble que c'est là que l'authentification doit être enregistrée. Et si la valeur reste vide, essaie de tracer les appels à SOAPAddress(), pour voir les adresses qui sont passées.
