Cookiejar vacío usando SUDS

Estoy ejecutando SUDS 0.4 en Linux Slackware 13.0 con python 2.6.2. Cuando llamo método de SOAP utilizando este código:Cookiejar vacío usando SUDS

from suds.client import Client 

client = Client(url='file:acctWeb.wsdl', 
       location='http://10.242.69.4:8088/pfmaccess') 

res = client.service.login(login='user',password='passwd')

recibo respuesta siguiente:

DEBUG:suds.transport.http:received: 
CODE: 200 
HEADERS: {'set-cookie': 'OSP_Ref=0000000573800052;Domain=10.242.69.4:8088;Path=/pfmaccess', 'content-length': '26541', 'content-type': 'text/xml; charset=utf-8', 'connection': 'close', 'server': 'Alcatel-Lucent OSP 2.4'}

pero

>>> client.options.transport.cookiejar 
<cookielib.CookieJar[]>

muestra que no hay galletas disponibles. ¿Cuál podría ser una razón para eso? No puedo usar SOAP API porque necesito pasar las credenciales enviadas en la cookie de respuesta.

Por favor, ayúdenme en esto.

rjan

Fuente

2012-01-19 rjan

Ok, he jugado un poco con él.

primero, un poco de servidor de prueba (courtesy of soaplib):

import soaplib 
from soaplib.core.service import rpc, DefinitionBase, soap 
from soaplib.core.model.primitive import String, Integer 
from soaplib.core.server import wsgi 
from soaplib.core.model.clazz import Array 
import sys, pprint 

class HelloWorldService(DefinitionBase): 
    @soap(String,Integer,_returns=Array(String)) 
    def say_hello(self,name,times): 
     results = [] 
     for i in range(0,times): 
      results.append('Hello, %s'%name) 
     return results 

class WsgiApp(wsgi.Application): 

    def on_wsgi_return(self, env, headers, return_str): 
     headers['Set-Cookie'] = 'spam=eggs;domain=127.0.0.1;path=/' 
     print >>sys.stderr, headers 

if __name__=='__main__': 
    try: 
     from wsgiref.simple_server import make_server 
     soap_application = soaplib.core.Application([HelloWorldService], 'tns') 
     wsgi_application = WsgiApp(soap_application) 
     server = make_server('localhost', 7789, wsgi_application) 
     server.serve_forever() 
    except ImportError: 
     print "Error: example server code requires Python >= 2.5"

con alguna pequeña modificación para establecer una cabecera de cookies.

y una espuma-TestClient:

from suds import client, transport 

c = client.Client("http://127.0.0.1:7789/?wsdl") 
print c.service.say_hello("spam", 1) 
print c.options.transport.cookiejar

ejecutar este produce:

(stringArray){ 
    string[] = 
     "Hello, spam", 
} 
<cookielib.CookieJar[<Cookie spam=eggs for .127.0.0.1/>]>

por lo que las costuras a trabajar. pero si cambia la solicitud de URL a http://localhost:7789/?wsdl obtendrá:

(stringArray){ 
    string[] = 
     "Hello, spam", 
} 
<cookielib.CookieJar[]>

encender algún registro para cookielib en el cliente ...

import logging 
import cookielib 
logging.basicConfig() 
logging.getLogger('cookielib').setLevel(logging.DEBUG) 
cookielib.debug = True

... Y revela revela por qué:

DEBUG:cookielib:add_cookie_header 
DEBUG:cookielib:extract_cookies: Date: Thu, 17 May 2012 15:56:01 GMT 
Server: WSGIServer/0.1 Python/2.7.3 
Set-Cookie: spam=eggs;domain=127.0.0.1;path=/ 
Content-Length: 822 
Content-Type: text/xml 

DEBUG:cookielib: - checking cookie spam=eggs 
DEBUG:cookielib: effective request-host localhost.local (even with added initial 
        dot) does not end with .127.0.0.1 
(stringArray){ 
    string[] = 
     "Hello, spam", 
} 
<cookielib.CookieJar[]>

la sencilla explicación es: el dominio de la cookie no coincide con el dominio del servidor de la solicitud, y como parece cookielib no hace ninguna de búsqueda cuando verifyi ng el dominio.

por lo que la solución podría ser uno de:

asegúrese de que el cliente y el servidor utilizan el mismo dominio (ya sea nombre de dominio o IP)
en el ejemplo que tengo que fijar tanto a localhost.local para que funcione (mayo Depende del archivo hosts ...)
eliminar el dominio de la cookie enviado, a continuación, utiliza el dominio cookieib solicitud automáticamente
implementar un CookieJar que utiliza las búsquedas de DNS

Ah, y por último, pero no menos importante: la razón por la que no lo hizo trabajar en la pregunta de OP:
el puerto no es parte del dominio, por lo que siempre se rechazará una cookie con Domain=10.242.69.4:8088.

Fuente

2012-05-17 16:17:55 mata

Respuesta

Cuestiones relacionadas