Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations

2007-10-22 Thread David Illsley
Hi Ruchith, Yes, I think tha handler should be in the addressing module, and so yes, I think we should use a property to allow the AxisOperation to be verified (and easily extracted by the security handlers). David On 19/10/2007, Ruchith Fernando [EMAIL PROTECTED] wrote: Hi David, I agree

Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations

2007-10-18 Thread Ruchith Fernando
Hi David, I agree with the proposal! Just one clarification though : Are we going to include the SecuredAddressingDispatchValidator in the addressing module? If so should we a property in the message context to point to the AxisOperation used for security configuration? Thanks, Ruchith On

Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations

2007-10-17 Thread David Illsley
Brian, No, I'd intend that the wsa:Action and wsa:RelatesTo be extracted just once in the AddressingDispatchExtractor and set the values on the MessageContext. David On 11/10/2007, Brian De Pradine [EMAIL PROTECTED] wrote: Hello David, Please see my comments below. Cheers Brian

Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations

2007-10-11 Thread Brian De Pradine
Hello David, Please see my comments below. Cheers Brian DePradine Web Services Development IBM Hursley External +44 (0) 1962 816319 Internal 246319 If you can't find the time to do it right the first time, where will you find the time to do it again? David Illsley [EMAIL PROTECTED]

[Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations

2007-10-09 Thread David Illsley
As discussed a couple of months back, the current one-shot WS-Addressing header extraction isn't suited for use with security. This is because either: 1. Addressing runs before security and populates fields such as ReplyTo/FaultTo which, if later found to be invalid would not be un(de?)populated