WS02 / WSF PHP 2.1.0 Problemi di nome utente
-
12-12-2019 - |
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:
- .
- Ho attivato le tracce di debug (livello log 4)
-
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
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!
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 ...