OVH Community, votre nouvel espace communautaire.

SOAP API .. rien ne va plus depuis hier ..


Ethaniel
10/09/2012, 15h05
Le problème vient de se fixer de mon côté également.
cbrassel
08/09/2012, 19h56
Je pense que le probleme vient de leurs manips sur les load balancer, je pense que j'avais une session sur mon ip bindé sur un mauvais serveur.

J'ai donc désactivé tous les test utilisant les api d'ovh hier après midi .. j'ai attendu plus de 24 heures, et maintenant tout fonctionne à nouveau parfaitement.

Fait de même et tout devrais ce résoudre tout seul ..

Ethaniel
07/09/2012, 13h15
Pareil. Sauf que sur mon serveur qui fait le SOAP, je n'ai jamais pu avoir le 405.

On est que 2 à avoir ce problème ou quoi ?
cbrassel
07/09/2012, 13h04
bon je pense que la piste est bonne :
en faisant plusieurs fois le curl j'obtient des réponses différentes, régulièrement des 302 et de temps en temps des 405 (ce qui est le comportement régulier sur mes autres machines.
voici un détails des curl :
Le 302:
Code:
curl -v https://www.ovh.com:1664
* About to connect() to www.ovh.com port 1664 (#0)
*   Trying 213.186.33.34... connected
* Connected to www.ovh.com (213.186.33.34) port 1664 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
*        subject: /serialNumber=424761419/1.3.6.1.4.1.311.60.2.1.3=FR/1.3.6.1.4.1.311.60.2.1.2=Nord/1.3.6.1.4.1.311.60.2.1.1=ROUBAIX/2.5.4.15=Private Organization/C=FR/postalCode=59100/ST=NORD/L=ROUBAIX/streetAddress=2 rue Kellermann/O=OVH/OU=0002 424761419/OU=Comodo EV SSL/CN=www.ovh.com
*        start date: 2010-11-15 00:00:00 GMT
*        expire date: 2012-12-14 23:59:59 GMT
*        subjectAltName: www.ovh.com matched
*        issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Extended Validation Secure Server CA
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: www.ovh.com:1664
> Accept: */*
> 
< HTTP/1.1 302 Found
< Set-Cookie: slb=R3935341425; path=/; expires=Sun, 09-Sep-2012 23:59:33 GMT
< Date: Fri, 07 Sep 2012 12:00:54 GMT
< Server: Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8g mod-xslt/1.3.9
< Location: https://www.ovh.com/fr/index.xml
< Cache-Control: max-age=60
< Expires: Fri, 07 Sep 2012 12:01:54 GMT
< Vary: Accept-Encoding
< Content-Length: 337
< Content-Type: text/html; charset=iso-8859-1
< 


302 Found


Found


The document has moved here.




Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8g mod-xslt/1.3.9 Server at www.ovh.com Port 443


* Connection #0 to host www.ovh.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
le 405 :

Code:
curl -v https://www.ovh.com:1664
* About to connect() to www.ovh.com port 1664 (#0)
*   Trying 213.186.33.34... connected
* Connected to www.ovh.com (213.186.33.34) port 1664 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
*        subject: /serialNumber=424761419/1.3.6.1.4.1.311.60.2.1.3=FR/1.3.6.1.4.1.311.60.2.1.2=Nord/1.3.6.1.4.1.311.60.2.1.1=ROUBAIX/2.5.4.15=Private Organization/C=FR/postalCode=59100/ST=NORD/L=ROUBAIX/streetAddress=2 rue Kellermann/O=OVH/OU=0002 424761419/OU=Comodo EV SSL/CN=www.ovh.com
*        start date: 2010-11-15 00:00:00 GMT
*        expire date: 2012-12-14 23:59:59 GMT
*        subjectAltName: www.ovh.com matched
*        issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Extended Validation Secure Server CA
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: www.ovh.com:1664
> Accept: */*
> 
< HTTP/1.1 405 Method Not Allowed
< Date: Fri, 07 Sep 2012 12:00:55 GMT
< Server: libwww-perl-daemon/5.827
< Connection: close
< 
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Ethaniel
07/09/2012, 13h02
J'ai constaté comme toi.
Mes scripts sur une autre machine fonctionne.
Comme je l'ai dit sur l'incident, je pense que c'est plus un ban du système de SOAP qu'autre chose.
Car je sais pas pour toi, mais dans "Log de Connexions Au Manager" , la tentative de notre serveur d'API n’apparaît pas.
cbrassel
07/09/2012, 12h53
Le probleme ne viendrait il pas de l'url :
https://www.ovh.com:1664 ??

sur le serveur qui ne fonctionne pas j'ai ça :
curl https://www.ovh.com:1664


302 Found

Found


The document has moved here.



Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8g mod-xslt/1.3.9 Server at www.ovh.com Port 443



et sur les machines ou les scripts fonctionnent le curl ne renvoi absolument rien ...

d'ailleurs en modifiant dans le script perl la ligne
Code:
proxy('https://www.ovh.com:1664');
j'obtiens le même résultat que sur le serveur ou ça ne marche plus ... piste à creuser je pense
cbrassel
07/09/2012, 12h33
Bonjour,

depuis hier je cherche de tout coté, le probleme semble être sur mon serveur .. enfin je pense ..
Voilà ce que j'observe :
1. depuis ma machine habituel ou j'execute les script (un linux sur lequel les scripts tournent depuis 2 ans maintenant) j'obtient des résultats aléatoires : une fois j'arrive au login, une fois j'arrive à récuperer ou modifier les infos et une fois je n'arrive même pas à me loger.
2. depuis d'autres machines (chez moi, d'autres serveurs linux .. 0 soucis, tout fonctionne toujours bien)

Donc je cherche la cause sur le serveur, mais ce qui me perturbe est que le probleme est le même en perl, php et je viens de faire le test en python.
Pour le test j'ai repris tel quel le script fournit en exemple sur le site http://www.ovh.com/soapi/fr/, voilà par exemple le résultat en python :
Code:
# python sms.py 
/usr/local/lib64/python2.6/site-packages/wstools-0.3-py2.6.egg/wstools/XMLSchema.py:3107: DeprecationWarning: object.__init__() takes no parameters
  tuple.__init__(self, args)
Traceback (most recent call last):
  File "sms.py", line 9, in 
    session = soap.login('xxxxxx', 'xxxxxx', 'fr', 0)
  File "build/bdist.linux-x86_64/egg/SOAPpy/Client.py", line 540, in __call__
  File "build/bdist.linux-x86_64/egg/SOAPpy/Client.py", line 562, in __r_call
  File "build/bdist.linux-x86_64/egg/SOAPpy/Client.py", line 425, in __call
  File "build/bdist.linux-x86_64/egg/SOAPpy/Client.py", line 324, in call
SOAPpy.Errors.HTTPError:
et voici le code :
Code:
#!/usr/bin/python

import pprint
from SOAPpy import WSDL

soap = WSDL.Proxy('https://www.ovh.com/soapi/soapi-re-1.47.wsdl')

#login
session = soap.login('xxxxx-OVH', 'xxxxxx', 'fr', 0)
print "login successfull"

#telephonySmsCreditLeft
result = soap.telephonySmsCreditLeft(session, 'sms-xxxxx')
print "telephonySmsCreditLeft successfull"
pp = pprint.PrettyPrinter(indent=4)
pp.pprint(result) # your code here ...

#logout
soap.logout(session)
print "logout successfull"
pour le perl j'ai comme résultat :
Code:
200 OK at sms.pl line 5.
et de temps en emps :
Code:
perl sms.pl
login successfull
200 OK at sms.pl line 5.
pour le script :
Code:
#!/usr/bin/perl

use Data::Dumper;
use SOAP::Lite
 on_fault => sub { my($soap, $res) = @_; die ref $res ? $res->faultstring : $soap->transport->status; };

my $soap = SOAP::Lite
 -> uri('https://soapi.ovh.com/manager')
 -> proxy('https://www.ovh.com:1664');

#login
my $result = $soap->call( 'login' => ('xxxxx-OVH', 'xxxxx', 'fr', 0) );
print "login successfull\n";
my $session = $result->result();

#telephonySmsCreditLeft
my $result = $soap->call( 'telephonySmsCreditLeft' => ($session, 'sms-xxxx') );
print "telephonySmsCreditLeft successfull\n";
my $return = $result->result();
print Dumper $return; # your code here ...

#logout
$soap->call( 'logout' => ( $session ) );
print "logout successfull\n";
Voilà .. la je ne sais plus quoi faire .. personne n'a fait de mise à jour sur le serveur, php, python et perl on le même problème et personne ne partage la même librairie ..

J'avoue que la .. je sèche un peu ..
Toute idée même saugrenue est la bien venu.

par contre ce qui me rassure c'est que je ne soit pas le seul
Ethaniel
07/09/2012, 10h33
Ticket incident : 1126785

J'ai mis tout les détails dedans.
LouisM
06/09/2012, 17h55
Pouvez-vous me fournir un exemple de code avec lequel vous avez cela ?
Je n'arrive pas a le reproduire de mon coté actuellement.
Ethaniel
06/09/2012, 15h11
Même erreur que toi. J'ai appelé le support et créer un incident.
Dès que j'aurai un retour, je te ferai savoir.
cbrassel
06/09/2012, 12h09
Bonjour,

J'utilise l'interface soap api pour faire des requêtes simples, connaitre le nb de sms dispo, la redirection de mon telephone etc ..

et depuis hier soir j'ai les messages suivants dans mes scrits :
en php :
SoapFault exception: [Client] looks like we got no XML document in xxxxx.php:7
Stack trace:
#0 /xxxxx.php(7): SoapClient->__call('login', Array)
#1 /xxxxx.php(7): SoapClient->login('client', 'password', 'fr', false)
#2 {main}

et en perl : j'ai juste un retour 200 OK.

J'ai bien vu qu'il fallait aussi cocher la case "soap" dans les restrictions d'accès .. mais à priori ça ne suffit pas.

Mardi soir ça fonctionnait encore et hier soir .. plus rien.

une idée ?

Merci

Claude