Domanda

Cerco di chiamare un partner ws usando usernametoken. Io uso per quel WS02 wsf_2.0.0 sotto PHP5.2.x e rocks. Ora vogliamo migrare su una soluzione diversa basata su PHP5.3, fortunatamente WS02 fornisce un tag 2.1.0 compatibile con PHP5.3. Prendo il tempo di leggere le nuove funzionalità e la documentazione di questa nuova versione e soprattutto riguardo al nome utente. Ho capito questa versione per l'uso della firma per quanto riguarda il nome utente durante una chiave certificata e privata. Immagino B / C della politica di AsymetricTransportBinding. Nel mio caso non volevo firmare nulla tramite il certificato o altro. Ho letto anche che WS02 fornisce una specie di fallback in un file XML separato per evitare qualsiasi firma.

Dopo aver letto molti post, forum ho bisogno di aiuto dalla comunità b / c sono totalmente bloccato.

Ecco il codice utilizzato per richiedere il WS in 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 );
.

A questo punto:

    .
  1. Ho attivato le tracce di debug (livello log 4)
  2. Confermò che il mio "a" sta usando HTTP accorendo la definizione WSDL

    wsdl: port name="calcolivicehttpport" binding="tns: calcolivicehttpbinding" wsdlsoap: indirizzo posizione="http://www.xxxx.xx/comparatorervices/calcraulationservice" / WSDL: PORTA

  3. Ora dai registri di debug, prendo questo:

    [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
    
    .

    Quindi la mia prima idea era di annusare il traffico e in particolare l'intestazione di sapone tra il lavoro (WSF_2.0.0 / PHP5.2.X) e la rottura (WSF_2.1.0 / PHP5.3)

    Ecco il 2.0.0 (funzionante)

        <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>
    
    .

    e il 2.1.0 (non funzionante / interruzione)

             <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>
    
    .

    Come puoi vedere l'unica differenza proveniente dal WSSSE: Security Namespace. (mancante XMLNS: saponev="http://schemas.xmlsoap.org/soap/envelope/)

    Ed è tutto ...

    Ispezione del rampart_in_handler.c alla riga 91 Secondo il registro Debug ha dichiarato:

    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;
        }
    
    .

    Significa che si sì .... The Soap_header è falso .. ma perché? C'è qualche ragazzo intelligente per spiegare cosa c'è che non va?

    Nota 1: Ho ispezionato la politica inviata al partner WS dal funzionamento (2.0.0) Sembra che sia usato un asimmetrico è usato ... che è strano quanto a lungo nel 2.0.0 non abbiamo fornito alcun certificato o chiavi.

    Nota 2: Ho anche provato a utilizzare il token del nome utente firmato con i classici parametri di array dell'oggetto wspolicy - ho creato un certificato X509 e PrivateKey, quindi utilizzare le funzioni per caricare questi file e utilizzare i parametri di array per caricarlo nel costruttore di wssecurity ... ma ricevo il Lo stesso errore / sniffing è un dolore B / C, i dati sono criptati o qualcosa del genere (che sembra essere normale in questo modo)

    Nota 3: Attualmente testato su Ubuntu10.04-3LS con i pacchetti PHP pre-compilati da APT-GET

    Aiuto PLZ!

È stato utile?

Soluzione

Alla fine ho trovato il problema e ho riparato il rampart_in_handler.c: 91

Il problema proveniva dalla risposta e non dalla richiesta ... Ho ispezionato attraverso un sniffer TCP e la risposta dal partner WS è stata effettuata senza sapone: intestazione.

Conforme o non con standard, con l'ultima versione (2.0.0) che funzionava. Così ho deciso di modificare un po 'il codice in rampart_in_handler.c per restituire un successo in caso di intestazione di sapone manca ...

Secondo me e PLZ correggimi se sbaglio:

Il test sulla risposta della soaphaader è stato aggiunto certamente B / C del trasporto asimmetrico e il nuovo caso di usernametoken firmato. Tuttavia, se vogliamo utilizzare USERNAMETOKEN senza firmare ( attraverso la politica di base.xml ) e La risposta è fatta senza alcun sapone: intestazione; Quindi Rampart restituirà sempre un fallimento ...

Inoltre, ho analizzato il codice PHP sotto gli script / cartella relativa al modo in cui WSF maneggia la risposta e ho visto su questo file: wsf_wsdl.php sotto la funzione 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);
}
.

Significato sul lato PHP, quando i dati vengono ricevuti, WSF / PHP Assumi un caso senza alcun soatracker ... (non c'è fallimento se manca il soapheader) super strano!?

Alla fine, ma non meno importante, ho trovato un bug strano su entrambi i file wsf_wsdl_serialization.php e wsf_wsdl_deserialization.php.

Ad esempio se si prevede di inviare e / o ricevere parametri / valori con una stringa del genere:

                            "110% Sigma of something" 
.

Non riuscirà a creare un segfault durante il processo serializza / unserialize!

Ora mi sto chiedendo perché? Ma ad una prima opinione, di sicuro, "110% Sig .." contiene "% s" ed è piuttosto chiuso di "% s" ...

Penso che questo bug sia questo menzionato qui:

http:// vecchio. nalebeb.com/wsf-php-server-segfault-on-wsf_wsdl_serialization.php---td24329956.html

Se cambio la S di D o qualsiasi altra cosa funziona ...

Che dolore ...

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top