it appears that the sigCrypto wasn't being set up properly because of a mismatch with the doAction bits - i had 2 <handler type="....WSDoAllReceiver"> elements in my server-config.wsdd (because i had different actors for UsernameToken and Signature), but when i removed the actors from my UsernameToken and Signature elements (because (a) they added no value that i know of and (b) i was having a hell of a time trying to add an actor attribute to the elements in the C# client) i forgot to consolidate my <handler> elements into 1 element with actions "UsernameToken Timestamp Signature".
so now get "security processing failed (actions mismatch)" which sounds familiar... after adding a little logging i see: action-id result-action-id UT (1) SIG TS (32) UT SIG(2) TS so the results of processing are in a different order than the actions entries themselves? the actions entry order is dictated by the order that appears in the server-config.wsdd - changing it fixed the C# client, but, you guessed it, broke the Java one. :-/ now that previous email makes sense - WSDoAllReceiver.invoke() is too big - if it were broken up by processing action we could sub-class it and change just the bit that needs fixing and not have to worry as much about upgrades. was there ever a non-invasive fix to this sequencing issue found? is the order really that important? i don't think i can reorder the actions on my Java client side to match the C# order, can i? ................ron. > Ron, > > at the receiver the order of elements during parsing and > processing is not important. > > According to the exception thrown it seems that you > don't have a Signature crypto file specified in the > WSDD (or otherwise) (parameter "signaturePropFile") or > the properties inside the sig-prop file are invalid. > > Regards, > Werner > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
