Problemas con WS02/WSF PHP 2.1.0 UsernameToken

https://stackoverflow.com//questions/11687135

12-12-2019
|

Pregunta

Intento llamar a un socio WS usando nombre de usuarioToken.Utilizo para eso ws02 wsf_2.0.0 en php5.2.x y es genial.Ahora queremos migrar a una solución diferente basada en php5.3; afortunadamente, ws02 proporciona una etiqueta 2.1.0 compatible con php5.3.Me tomo el tiempo para leer las nuevas características y documentación de esta nueva versión y especialmente con respecto al nombre de usuarioToken.Entendí que esta autorización utiliza la firma con respecto al nombre de usuarioToken a través de un certificado y una clave privada.Supongo que se debe a la política AsymetricTransportBinding.En mi caso no quería firmar nada mediante certificado ni nada por el estilo.También leí que ws02 proporciona una especie de respaldo en un archivo xml separado para evitar cualquier firma.

Después de leer muchas publicaciones y foros, necesito ayuda de la comunidad porque estoy totalmente estancado.

Aquí está el código utilizado para solicitar el WS en php5.3 - wsf 2.1.0 (usando HTTP)

$policy   = new \WSPolicy( $policy ); ( $policy is the one from the call_back folder with a file_get_contents() )

$security = new \WSSecurityToken( array(
  'user'                    => 'my_username',
  'password'                => 'my_password',
  'passwordType'            => 'Digest',
  'ttl'                     => '300'
));

$this->oSoapClient = new \WSClient( array(
  wsdl:          http://www.xxx.xx/comparatorservices/CalculationService?WSDL
  to:            http://www.xxx.xx/comparatorservices/CalculationService
  useWSA:        true
  useSOAP:       1.1,
  policy:        $policy,
  securityToken: $security
));

$proxy = $this->oSoapClient->getProxy();
$response = $proxy->wykonajKalkulacje( $MySuperRequestObject );

En este paso:

Activé los seguimientos de depuración (nivel de registro 4)
Confirmo que mi "para" está usando http según la definición de wsdl

wsdl: puerto name = "CALETLETRESEVICEHTTPPORT" Binding = "TNS: CculationServiceHttpBinding" WSDLSOAP: Dirección Ubicación = "http: //www.xxxx.xx/Comparatorservices/CalCationservice"/WSDL: Port

Ahora, de los registros de depuración, capto esto:

[Wed Jul 25 05:22:53 2012] [error] rampart_in_handler.c(91) [rampart]SOAP header cannot be found.
[Wed Jul 25 05:22:53 2012] [error] phase.c(224) Handler RampartInHandler invoke failed within phase Security
[Wed Jul 25 05:22:53 2012] [error] engine.c(657) Invoking phase Security failed
[Wed Jul 25 05:22:53 2012] [error] engine.c(262) Invoking operation specific phases failed for operation __OPERATION_OUT_IN__
[Wed Jul 25 05:22:53 2012] [error] /home/agruet/08_KRK_sources/wso2-wsf-php-src-2.1.0/src/wsf_wsdl.c(1226)      [wsf_wsdl] Response envelope not found

Así que mi primera idea fue detectar el tráfico y especialmente el encabezado SOAP entre el trabajo (wsf_2.0.0/php5.2.x) y el roto (wsf_2.1.0/php5.3).

Aquí está el 2.0.0 (funcionando)

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

        <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>my_username</wsse:Username>

            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">
              hashed(my_password)
            </wsse:Password>

            <wsse:Nonce>hashed</wsse:Nonce>
            <wsu:Created>2012-07-26T20:40:26.991Z</wsu:Created>

        </wsse:UsernameToken>
    </wsse:Security>
</soapenv:Header>

Y el 2.1.0 (no funciona/roto)

         <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
       <soapenv:Header>
         <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">

        <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

            <wsse:Username>my_username</wsse:Username>
            <wsse:Password
                Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">hashed(my_password)</wsse:Password>
            <wsse:Nonce>hashed</wsse:Nonce>
            <wsu:Created>2012-07-25T00:44:56.758Z</wsu:Created>
        </wsse:UsernameToken>
    </wsse:Security>
</soapenv:Header>

Como puede ver, la única diferencia proviene del espacio de nombres wsse:Security.(faltan xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/)

Y eso es todo ...

La inspección de rampart_in_handler.c en la línea 91 de acuerdo con el registro de depuración decía:

soap_header = axiom_soap_envelope_get_header(soap_envelope, env);
    if(!soap_header)
    {
        /*No SOAP header, so no point of proceeding. FAIL*/
        AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "[rampart]SOAP header cannot be found.");
        return AXIS2_FAILURE;
    }

Es decir, sí....el encabezado_jabón es falso.¿pero por qué?¿Hay algún tipo inteligente para explicar lo que pasa?

nota 1:Inspeccioné la política enviada al socio WS desde el funcionamiento (2.0.0). Parece que se usa AsymetricBinding...Lo cual es extraño siempre y cuando en la versión 2.0.0 no proporcionemos ningún certificado o clave.

nota 2:También intenté usar un token de nombre de usuario firmado con los parámetros de matriz de objetos WSPolicy clásicos: creé un certificado x509 y una clave privada, luego usé las funciones para cargar estos archivos y usé los parámetros de matriz para cargarlos en el Constructor WSSecurity...pero recibo el mismo error/Olfatear es una molestia porque los datos están encriptados o algo así (lo que parece ser normal de esta manera)

nota 3:Actualmente probado en Ubuntu10.04-3LTS con los paquetes php precompilados de apt-get

¡AYUDA POR FAVOR!

Solución

Finalmente encontré el problema y solucioné rampart_in_handler.c:91

El problema venía de la respuesta y no de la solicitud...Inspeccioné a través de un rastreador tcp y la respuesta del socio WS se realizó sin ningún jabón: encabezado.

Cumple o no con los estándares, con la última versión (2.0.0) estaba funcionando.Así que decidí modificar un poco el código en el archivo rampart_in_handler.c para devolver un resultado exitoso en el caso de que faltara el encabezado SOAP...

En mi opinión y por favor corríjanme si me equivoco:

La prueba en la respuesta de SoapHeader se agregó ciertamente debido al transporte asimétricoBinding y el nuevo caso del token de nombre de usuario firmado.Sin embargo, si queremos utilizar el token de nombre de usuario sin firmar ( a través de la política básica.xml ) Y la respuesta se realiza sin jabón:Encabezado;Entonces Rampart siempre devolverá un fracaso...

Además, analicé el código php en la carpeta scripts/ con respecto a la forma en que wsf maneja la respuesta y vi en este archivo: wsf_wsdl.php bajo la función wsf_process_response() :

if($response_header_string && !empty($response_header_string)) {
    $header_dom = new DomDocument();
    $header_dom->preserveWhiteSpace = FALSE;
    $header_dom->loadXML($response_header_string);
}

Es decir, en el lado de php, cuando se reciben los datos, wsf/php asume un caso sin ningún encabezado de jabón...(no hay falla si falta el encabezado del jabón) ¿¡Súper raro!?

Por último, pero no menos importante, encontré un error extraño en ambos. wsf_wsdl_serialization.php y wsf_wsdl_deserialization.php archivos.

Por ejemplo, si planea enviar y/o recibir parámetros/valores con una cadena como esta:

                            "110% Sigma of something"

¡Fallará y creará un error de segmentación durante el proceso de serialización/deserializar!

Ahora me pregunto ¿por qué?Pero a primera vista, seguro, "110% Sig.." contiene "% S" y está bastante cerrado de "%s"...

Creo que este error es el que se menciona aquí:

http://old.nabble.com/WSF-PHP-server-segfault-on-wsf_wsdl_serialization.php---td24329956.html

Si cambio la S por D o cualquier otra cosa funciona...

Que dolor...

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow