La versione di WSSReceiver.java allegata ripulisce l'header di WSS sia
filtrando sull'"actor" (se definito come parametro e presente nel messaggio in
entrata) e quindi lasciando inalterato un eventuale header WSS presente nel
messaggio originale (questo non l'ho ancora provato personalmente) oppure se è
assente il parametro "actor" elimina il primo header WSS trovato (in questo
caso dovrebbe essere anche l'unico).
Questo permette di operare correttamente anche con altre porte di dominio dove
non è possibile definire l'actor nell'header WSS.
Inoltre ho aggiunto la pulizia di attributi e namespace relativi WSS nel body
quando dopo la pulizia dell'header non ci siano più header WSS.
Ciao
Luciano
-----Messaggio originale-----
Da: sviluppatori-bounces@openspcoop.org
[mailto:sviluppatori-bounces@openspcoop.org] Per conto di Andrea Poli
Inviato: martedì 16 maggio 2006 15.04
A: sviluppatori@openspcoop.org
Oggetto: Re: R: [OpenSPCoop-Dev] Interoperabilità con WS-Security e nuova
versione WSS4J ed Axis (1/2)
Montebove Luciano wrote:
> Andrea, ho fatto dei test facendomi scrivere da WSSReceiver e WSSSender
> l'envelope SOAP prima e dopo la invoke di WSDoAllReceiver e WSDoAllSender.
> Nel caso di WSSReceiver prendo l'envelope SOAP dopo la chiamata a
> envelope.getHeader().extractHeaderElements(actor);
> in modo da verificare l'eliminazione dell'header WSS. Questa avviene
> regolarmente anche nel caso di 'sbustamento-soap=false'. Lo puoi verificare
> con la versione di WSSReceiver allegata.
> Il problema è che però al WSSSender in input arriva l'envelope originale con
> l'header WSS.
> E' come se nella preparazione della risposta venisse usato il messaggio
> originale, non quello ripulito dall'header WSS.
>
Infatti succedeva proprio quello. Dopo aver processato il messaggio Soap, con
la classe WSSReceiver, ho dovuto aggiungere la chiamata del metodo
'saveChanges' sul messaggio Axis passato a WSSReceiver.
Prima non era necessario poiche' nella versione precedente di axis, il
salvataggio era automaticamente effettuato.
Adesso funziona tutto correttamente (ho fatto il commit sul CVS)
> Mi spieghi meglio la differenza di comportamento tra 'sbustamento-soap=false'
> e 'sbustamento-soap=true'?
>
sbustamento-soap=true significa che la porta di dominio OpenSPCoop utilizza
come servizio di consegna applicativa una HTTP Post che contiene solo il
contenuto del SoapBody (l'xml interno).
sbustamento-soap=false significa invece che la porta di dominio effettua una
invocazione di servizio SOAP (WebService).
Nell scenario che stiamo provando, la servlet 'TRACE_ECHO' associata alla porta
applicativa 'EchoWSS' non fa altro rispedire nella reply della connessione
TUTTO cio' che riceve.
Quindi se si usa sbustamento-soap=true, la servlet riceve e rispedisce solo
l'XML del Body. La porta di dominio riceve come risposta all'invocazione della
servlet l'XML, e quindi lo inserisce in un nuovo messaggio Soap (chiaramente
senza header) per poi processarlo normalmente (aggiungendo l'header eGov).
In questo contesto anche se non viene consumato l'header WSS, verra' poi
'eliminato' dal servizio di consegna di OpenSPcoop (utilizza solo il contenuto
del body) e per questo non si presenta l'errore.
Con sbustamento-soap=true, invece la servlet ricevere i byte formanti un
messaggio soap, i quali sono rispediti come risposta. La porta di dominio
quindi riceve gia' un messaggio Soap (che contiene il WSSHeader se non viene
consumato!!) ed utilizza quello per formare la risposta eGov. In questo
contesto, se non si consuma l'header WSS avviene l'errore.
Andrea.
_______________________________________________
Sviluppatori mailing list
Sviluppatori@openspcoop.org
http://www.openspcoop.org/mailman/listinfo/sviluppatori
WSSReceiver.java
Description: WSSReceiver.java
|