You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Uthaiyashankar <sh...@wso2.com> on 2008/05/28 08:51:43 UTC

soap action based dispatching with rampart

Hi,

Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
Due to that, if a message is having only soap action (no operation is 
specified in url or no wsa:action is given, so only possible way of 
dispatching is based on soap action) and message is secured, security 
cannot be verified. This is because, rampart needs operation to be 
resolved before verifying the security of the message. If the message is 
having only soap action, then when message comes to rampart, still the 
operation is not resolved.

Can somebody confirm soap action based dispatching happening on 
"PreDispatch"? If so, can we introduce another phase "Security" between 
"PreDispatch" and "Dispatch" and install rampart-in-handler to 
"Security" phase? will it cause any problem?  Any reason why 
rampart-in-handler is installed in "PreDispatch" phase rather than 
another phase? (I tried it and it worked)

Comments are welcome.

Regards,
Shankar.

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Re: soap action based dispatching with rampart

Posted by Kaushalye Kapuruge <ka...@wso2.com>.
Uthaiyashankar wrote:
> Hi,
>
> Currently rampart in-handler is called in "PreDispatch" phase in 
> inflow. Due to that, if a message is having only soap action (no 
> operation is specified in url or no wsa:action is given, so only 
> possible way of dispatching is based on soap action) and message is 
> secured, security cannot be verified. This is because, rampart needs 
> operation to be resolved before verifying the security of the message. 
> If the message is having only soap action, then when message comes to 
> rampart, still the operation is not resolved.
>
> Can somebody confirm soap action based dispatching happening on 
> "PreDispatch"? If so, can we introduce another phase "Security" 
> between "PreDispatch" and "Dispatch" and install rampart-in-handler to 
> "Security" phase? 
+1. We have done the same for the Out handler. So it's not a problem.
-Kau
> will it cause any problem?  Any reason why rampart-in-handler is 
> installed in "PreDispatch" phase rather than another phase? (I tried 
> it and it worked)
>
> Comments are welcome.
>
> Regards,
> Shankar.
>


-- 
http://blog.kaushalye.org/
http://wso2.org/


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Re: soap action based dispatching with rampart

Posted by Kaushalye Kapuruge <ka...@wso2.com>.
Uthaiyashankar wrote:
> Hi,
>
> Currently rampart in-handler is called in "PreDispatch" phase in 
> inflow. Due to that, if a message is having only soap action (no 
> operation is specified in url or no wsa:action is given, so only 
> possible way of dispatching is based on soap action) and message is 
> secured, security cannot be verified. This is because, rampart needs 
> operation to be resolved before verifying the security of the message. 
> If the message is having only soap action, then when message comes to 
> rampart, still the operation is not resolved.
>
> Can somebody confirm soap action based dispatching happening on 
> "PreDispatch"? If so, can we introduce another phase "Security" 
> between "PreDispatch" and "Dispatch" and install rampart-in-handler to 
> "Security" phase? 
+1. We have done the same for the Out handler. So it's not a problem.
-Kau
> will it cause any problem?  Any reason why rampart-in-handler is 
> installed in "PreDispatch" phase rather than another phase? (I tried 
> it and it worked)
>
> Comments are welcome.
>
> Regards,
> Shankar.
>


-- 
http://blog.kaushalye.org/
http://wso2.org/


Re: soap action based dispatching with rampart

Posted by Manjula Peiris <ma...@wso2.com>.
On Wed, 2008-05-28 at 15:11 +0530, Uthaiyashankar wrote:
> Hi,
> 
> This article [1] written by Samisa explicitly saying we can add user 
> defined phases only after pre-defined phases in in-flow. I guess it is 
> added purposely. Then we have to consider some other options to invoke 
> rampart after soap action based dispatching.

We may put soap action based dispatching in the transport phase. I don't
know whether that is the correct solution. One more thing, if the user
defined phases should be added after the pre-defined phases then Axis2/C
should give an error and shouldn't start the server when a user defined
phases are added before those pre-defined phases. Otherwise it is really
misleading.

Thanks,
-Manjula.

> 
> Regards,
> Shankar
> 
> [1] http://wso2.org/library/777
> 
> 
> Kaushalye Kapuruge wrote:
> > Thanks Manjula for this finding.
> > Is this a bug or added purposely?
> > Are there any problems if module defined phases get invoked before the 
> > default phases?
> > If not definitely need to fix this phase ordering problem in Axis2/C.
> > Cheers,
> > Kaushalye
> >
> > Manjula Peiris wrote:
> >> Hi,
> >>
> >> I debug the code. What is happening here is Security phase always
> >> invokes at last even you put it before Transport phase. Since soap
> >> action based dispatcher is in Dispatch phase in this situation when it
> >> comes to Rampart actual dispatching has occurred. So this means Axis2/C
> >> always invoke module defined phases after invoking its default phases. I
> >> think we need to fix this. I will raise a JIRA.
> >>
> >> Thanks,
> >> -Manjula.
> >>
> >>  
> >>
> >> On Wed, 2008-05-28 at 14:18 +0530, Manjula Peiris wrote:
> >>  
> >>> On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
> >>>    
> >>>> Shankar,
> >>>>
> >>>> I have tested Rampart/C with a soap action(without addressing) and
> >>>> putting the Security phase even before Transport phase and it 
> >>>> worked. So
> >>>> I think what is happening in this case is that actual dispatching does
> >>>> not happen from soap action phase dispatcher.
> >>>>       
> >>> not happen from soap action based dispatcher.
> >>>
> >>>    
> >>>>  
> >>>>
> >>>> -Manjula.
> >>>>
> >>>> On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
> >>>>      
> >>>>> Hi,
> >>>>>
> >>>>> Currently rampart in-handler is called in "PreDispatch" phase in 
> >>>>> inflow. Due to that, if a message is having only soap action (no 
> >>>>> operation is specified in url or no wsa:action is given, so only 
> >>>>> possible way of dispatching is based on soap action) and message 
> >>>>> is secured, security cannot be verified. This is because, rampart 
> >>>>> needs operation to be resolved before verifying the security of 
> >>>>> the message. If the message is having only soap action, then when 
> >>>>> message comes to rampart, still the operation is not resolved.
> >>>>>
> >>>>> Can somebody confirm soap action based dispatching happening on 
> >>>>> "PreDispatch"? If so, can we introduce another phase "Security" 
> >>>>> between "PreDispatch" and "Dispatch" and install 
> >>>>> rampart-in-handler to "Security" phase? will it cause any 
> >>>>> problem?  Any reason why rampart-in-handler is installed in 
> >>>>> "PreDispatch" phase rather than another phase? (I tried it and it 
> >>>>> worked)
> >>>>>
> >>>>> Comments are welcome.
> >>>>>
> >>>>> Regards,
> >>>>> Shankar.
> >>>>>         
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>>>
> >>>>       
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>>
> >>>     
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>
> >>
> >>   
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Re: soap action based dispatching with rampart

Posted by Manjula Peiris <ma...@wso2.com>.
On Wed, 2008-05-28 at 15:11 +0530, Uthaiyashankar wrote:
> Hi,
> 
> This article [1] written by Samisa explicitly saying we can add user 
> defined phases only after pre-defined phases in in-flow. I guess it is 
> added purposely. Then we have to consider some other options to invoke 
> rampart after soap action based dispatching.

We may put soap action based dispatching in the transport phase. I don't
know whether that is the correct solution. One more thing, if the user
defined phases should be added after the pre-defined phases then Axis2/C
should give an error and shouldn't start the server when a user defined
phases are added before those pre-defined phases. Otherwise it is really
misleading.

Thanks,
-Manjula.

> 
> Regards,
> Shankar
> 
> [1] http://wso2.org/library/777
> 
> 
> Kaushalye Kapuruge wrote:
> > Thanks Manjula for this finding.
> > Is this a bug or added purposely?
> > Are there any problems if module defined phases get invoked before the 
> > default phases?
> > If not definitely need to fix this phase ordering problem in Axis2/C.
> > Cheers,
> > Kaushalye
> >
> > Manjula Peiris wrote:
> >> Hi,
> >>
> >> I debug the code. What is happening here is Security phase always
> >> invokes at last even you put it before Transport phase. Since soap
> >> action based dispatcher is in Dispatch phase in this situation when it
> >> comes to Rampart actual dispatching has occurred. So this means Axis2/C
> >> always invoke module defined phases after invoking its default phases. I
> >> think we need to fix this. I will raise a JIRA.
> >>
> >> Thanks,
> >> -Manjula.
> >>
> >>  
> >>
> >> On Wed, 2008-05-28 at 14:18 +0530, Manjula Peiris wrote:
> >>  
> >>> On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
> >>>    
> >>>> Shankar,
> >>>>
> >>>> I have tested Rampart/C with a soap action(without addressing) and
> >>>> putting the Security phase even before Transport phase and it 
> >>>> worked. So
> >>>> I think what is happening in this case is that actual dispatching does
> >>>> not happen from soap action phase dispatcher.
> >>>>       
> >>> not happen from soap action based dispatcher.
> >>>
> >>>    
> >>>>  
> >>>>
> >>>> -Manjula.
> >>>>
> >>>> On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
> >>>>      
> >>>>> Hi,
> >>>>>
> >>>>> Currently rampart in-handler is called in "PreDispatch" phase in 
> >>>>> inflow. Due to that, if a message is having only soap action (no 
> >>>>> operation is specified in url or no wsa:action is given, so only 
> >>>>> possible way of dispatching is based on soap action) and message 
> >>>>> is secured, security cannot be verified. This is because, rampart 
> >>>>> needs operation to be resolved before verifying the security of 
> >>>>> the message. If the message is having only soap action, then when 
> >>>>> message comes to rampart, still the operation is not resolved.
> >>>>>
> >>>>> Can somebody confirm soap action based dispatching happening on 
> >>>>> "PreDispatch"? If so, can we introduce another phase "Security" 
> >>>>> between "PreDispatch" and "Dispatch" and install 
> >>>>> rampart-in-handler to "Security" phase? will it cause any 
> >>>>> problem?  Any reason why rampart-in-handler is installed in 
> >>>>> "PreDispatch" phase rather than another phase? (I tried it and it 
> >>>>> worked)
> >>>>>
> >>>>> Comments are welcome.
> >>>>>
> >>>>> Regards,
> >>>>> Shankar.
> >>>>>         
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>>>
> >>>>       
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>>
> >>>     
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >>
> >>
> >>   
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> 


Re: soap action based dispatching with rampart

Posted by Uthaiyashankar <sh...@wso2.com>.
Hi,

This article [1] written by Samisa explicitly saying we can add user 
defined phases only after pre-defined phases in in-flow. I guess it is 
added purposely. Then we have to consider some other options to invoke 
rampart after soap action based dispatching.

Regards,
Shankar

[1] http://wso2.org/library/777


Kaushalye Kapuruge wrote:
> Thanks Manjula for this finding.
> Is this a bug or added purposely?
> Are there any problems if module defined phases get invoked before the 
> default phases?
> If not definitely need to fix this phase ordering problem in Axis2/C.
> Cheers,
> Kaushalye
>
> Manjula Peiris wrote:
>> Hi,
>>
>> I debug the code. What is happening here is Security phase always
>> invokes at last even you put it before Transport phase. Since soap
>> action based dispatcher is in Dispatch phase in this situation when it
>> comes to Rampart actual dispatching has occurred. So this means Axis2/C
>> always invoke module defined phases after invoking its default phases. I
>> think we need to fix this. I will raise a JIRA.
>>
>> Thanks,
>> -Manjula.
>>
>>  
>>
>> On Wed, 2008-05-28 at 14:18 +0530, Manjula Peiris wrote:
>>  
>>> On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
>>>    
>>>> Shankar,
>>>>
>>>> I have tested Rampart/C with a soap action(without addressing) and
>>>> putting the Security phase even before Transport phase and it 
>>>> worked. So
>>>> I think what is happening in this case is that actual dispatching does
>>>> not happen from soap action phase dispatcher.
>>>>       
>>> not happen from soap action based dispatcher.
>>>
>>>    
>>>>  
>>>>
>>>> -Manjula.
>>>>
>>>> On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
>>>>      
>>>>> Hi,
>>>>>
>>>>> Currently rampart in-handler is called in "PreDispatch" phase in 
>>>>> inflow. Due to that, if a message is having only soap action (no 
>>>>> operation is specified in url or no wsa:action is given, so only 
>>>>> possible way of dispatching is based on soap action) and message 
>>>>> is secured, security cannot be verified. This is because, rampart 
>>>>> needs operation to be resolved before verifying the security of 
>>>>> the message. If the message is having only soap action, then when 
>>>>> message comes to rampart, still the operation is not resolved.
>>>>>
>>>>> Can somebody confirm soap action based dispatching happening on 
>>>>> "PreDispatch"? If so, can we introduce another phase "Security" 
>>>>> between "PreDispatch" and "Dispatch" and install 
>>>>> rampart-in-handler to "Security" phase? will it cause any 
>>>>> problem?  Any reason why rampart-in-handler is installed in 
>>>>> "PreDispatch" phase rather than another phase? (I tried it and it 
>>>>> worked)
>>>>>
>>>>> Comments are welcome.
>>>>>
>>>>> Regards,
>>>>> Shankar.
>>>>>         
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>>
>>>>       
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>     
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>   
>
>


Re: soap action based dispatching with rampart

Posted by Uthaiyashankar <sh...@wso2.com>.
Hi,

This article [1] written by Samisa explicitly saying we can add user 
defined phases only after pre-defined phases in in-flow. I guess it is 
added purposely. Then we have to consider some other options to invoke 
rampart after soap action based dispatching.

Regards,
Shankar

[1] http://wso2.org/library/777


Kaushalye Kapuruge wrote:
> Thanks Manjula for this finding.
> Is this a bug or added purposely?
> Are there any problems if module defined phases get invoked before the 
> default phases?
> If not definitely need to fix this phase ordering problem in Axis2/C.
> Cheers,
> Kaushalye
>
> Manjula Peiris wrote:
>> Hi,
>>
>> I debug the code. What is happening here is Security phase always
>> invokes at last even you put it before Transport phase. Since soap
>> action based dispatcher is in Dispatch phase in this situation when it
>> comes to Rampart actual dispatching has occurred. So this means Axis2/C
>> always invoke module defined phases after invoking its default phases. I
>> think we need to fix this. I will raise a JIRA.
>>
>> Thanks,
>> -Manjula.
>>
>>  
>>
>> On Wed, 2008-05-28 at 14:18 +0530, Manjula Peiris wrote:
>>  
>>> On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
>>>    
>>>> Shankar,
>>>>
>>>> I have tested Rampart/C with a soap action(without addressing) and
>>>> putting the Security phase even before Transport phase and it 
>>>> worked. So
>>>> I think what is happening in this case is that actual dispatching does
>>>> not happen from soap action phase dispatcher.
>>>>       
>>> not happen from soap action based dispatcher.
>>>
>>>    
>>>>  
>>>>
>>>> -Manjula.
>>>>
>>>> On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
>>>>      
>>>>> Hi,
>>>>>
>>>>> Currently rampart in-handler is called in "PreDispatch" phase in 
>>>>> inflow. Due to that, if a message is having only soap action (no 
>>>>> operation is specified in url or no wsa:action is given, so only 
>>>>> possible way of dispatching is based on soap action) and message 
>>>>> is secured, security cannot be verified. This is because, rampart 
>>>>> needs operation to be resolved before verifying the security of 
>>>>> the message. If the message is having only soap action, then when 
>>>>> message comes to rampart, still the operation is not resolved.
>>>>>
>>>>> Can somebody confirm soap action based dispatching happening on 
>>>>> "PreDispatch"? If so, can we introduce another phase "Security" 
>>>>> between "PreDispatch" and "Dispatch" and install 
>>>>> rampart-in-handler to "Security" phase? will it cause any 
>>>>> problem?  Any reason why rampart-in-handler is installed in 
>>>>> "PreDispatch" phase rather than another phase? (I tried it and it 
>>>>> worked)
>>>>>
>>>>> Comments are welcome.
>>>>>
>>>>> Regards,
>>>>> Shankar.
>>>>>         
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>>
>>>>       
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>     
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>   
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Re: soap action based dispatching with rampart

Posted by Kaushalye Kapuruge <ka...@wso2.com>.
Thanks Manjula for this finding.
Is this a bug or added purposely?
Are there any problems if module defined phases get invoked before the 
default phases?
If not definitely need to fix this phase ordering problem in Axis2/C.
Cheers,
Kaushalye

Manjula Peiris wrote:
> Hi,
>
> I debug the code. What is happening here is Security phase always
> invokes at last even you put it before Transport phase. Since soap
> action based dispatcher is in Dispatch phase in this situation when it
> comes to Rampart actual dispatching has occurred. So this means Axis2/C
> always invoke module defined phases after invoking its default phases. I
> think we need to fix this. I will raise a JIRA.
>
> Thanks,
> -Manjula.
>
>   
>
>
> On Wed, 2008-05-28 at 14:18 +0530, Manjula Peiris wrote:
>   
>> On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
>>     
>>> Shankar,
>>>
>>> I have tested Rampart/C with a soap action(without addressing) and
>>> putting the Security phase even before Transport phase and it worked. So
>>> I think what is happening in this case is that actual dispatching does
>>> not happen from soap action phase dispatcher.
>>>       
>> not happen from soap action based dispatcher.
>>
>>     
>>>  
>>>
>>> -Manjula. 
>>>
>>>
>>> On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
>>>       
>>>> Hi,
>>>>
>>>> Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
>>>> Due to that, if a message is having only soap action (no operation is 
>>>> specified in url or no wsa:action is given, so only possible way of 
>>>> dispatching is based on soap action) and message is secured, security 
>>>> cannot be verified. This is because, rampart needs operation to be 
>>>> resolved before verifying the security of the message. If the message is 
>>>> having only soap action, then when message comes to rampart, still the 
>>>> operation is not resolved.
>>>>
>>>> Can somebody confirm soap action based dispatching happening on 
>>>> "PreDispatch"? If so, can we introduce another phase "Security" between 
>>>> "PreDispatch" and "Dispatch" and install rampart-in-handler to 
>>>> "Security" phase? will it cause any problem?  Any reason why 
>>>> rampart-in-handler is installed in "PreDispatch" phase rather than 
>>>> another phase? (I tried it and it worked)
>>>>
>>>> Comments are welcome.
>>>>
>>>> Regards,
>>>> Shankar.
>>>>         
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>   


-- 
http://blog.kaushalye.org/
http://wso2.org/


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Re: soap action based dispatching with rampart

Posted by Kaushalye Kapuruge <ka...@wso2.com>.
Thanks Manjula for this finding.
Is this a bug or added purposely?
Are there any problems if module defined phases get invoked before the 
default phases?
If not definitely need to fix this phase ordering problem in Axis2/C.
Cheers,
Kaushalye

Manjula Peiris wrote:
> Hi,
>
> I debug the code. What is happening here is Security phase always
> invokes at last even you put it before Transport phase. Since soap
> action based dispatcher is in Dispatch phase in this situation when it
> comes to Rampart actual dispatching has occurred. So this means Axis2/C
> always invoke module defined phases after invoking its default phases. I
> think we need to fix this. I will raise a JIRA.
>
> Thanks,
> -Manjula.
>
>   
>
>
> On Wed, 2008-05-28 at 14:18 +0530, Manjula Peiris wrote:
>   
>> On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
>>     
>>> Shankar,
>>>
>>> I have tested Rampart/C with a soap action(without addressing) and
>>> putting the Security phase even before Transport phase and it worked. So
>>> I think what is happening in this case is that actual dispatching does
>>> not happen from soap action phase dispatcher.
>>>       
>> not happen from soap action based dispatcher.
>>
>>     
>>>  
>>>
>>> -Manjula. 
>>>
>>>
>>> On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
>>>       
>>>> Hi,
>>>>
>>>> Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
>>>> Due to that, if a message is having only soap action (no operation is 
>>>> specified in url or no wsa:action is given, so only possible way of 
>>>> dispatching is based on soap action) and message is secured, security 
>>>> cannot be verified. This is because, rampart needs operation to be 
>>>> resolved before verifying the security of the message. If the message is 
>>>> having only soap action, then when message comes to rampart, still the 
>>>> operation is not resolved.
>>>>
>>>> Can somebody confirm soap action based dispatching happening on 
>>>> "PreDispatch"? If so, can we introduce another phase "Security" between 
>>>> "PreDispatch" and "Dispatch" and install rampart-in-handler to 
>>>> "Security" phase? will it cause any problem?  Any reason why 
>>>> rampart-in-handler is installed in "PreDispatch" phase rather than 
>>>> another phase? (I tried it and it worked)
>>>>
>>>> Comments are welcome.
>>>>
>>>> Regards,
>>>> Shankar.
>>>>         
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>   


-- 
http://blog.kaushalye.org/
http://wso2.org/


Re: soap action based dispatching with rampart

Posted by Manjula Peiris <ma...@wso2.com>.
Hi,

I debug the code. What is happening here is Security phase always
invokes at last even you put it before Transport phase. Since soap
action based dispatcher is in Dispatch phase in this situation when it
comes to Rampart actual dispatching has occurred. So this means Axis2/C
always invoke module defined phases after invoking its default phases. I
think we need to fix this. I will raise a JIRA.

Thanks,
-Manjula.

  


On Wed, 2008-05-28 at 14:18 +0530, Manjula Peiris wrote:
> On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
> > Shankar,
> > 
> > I have tested Rampart/C with a soap action(without addressing) and
> > putting the Security phase even before Transport phase and it worked. So
> > I think what is happening in this case is that actual dispatching does
> > not happen from soap action phase dispatcher.
> not happen from soap action based dispatcher.
> 
> >  
> > 
> > -Manjula. 
> > 
> > 
> > On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
> > > Hi,
> > > 
> > > Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
> > > Due to that, if a message is having only soap action (no operation is 
> > > specified in url or no wsa:action is given, so only possible way of 
> > > dispatching is based on soap action) and message is secured, security 
> > > cannot be verified. This is because, rampart needs operation to be 
> > > resolved before verifying the security of the message. If the message is 
> > > having only soap action, then when message comes to rampart, still the 
> > > operation is not resolved.
> > > 
> > > Can somebody confirm soap action based dispatching happening on 
> > > "PreDispatch"? If so, can we introduce another phase "Security" between 
> > > "PreDispatch" and "Dispatch" and install rampart-in-handler to 
> > > "Security" phase? will it cause any problem?  Any reason why 
> > > rampart-in-handler is installed in "PreDispatch" phase rather than 
> > > another phase? (I tried it and it worked)
> > > 
> > > Comments are welcome.
> > > 
> > > Regards,
> > > Shankar.
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> 


Re: soap action based dispatching with rampart

Posted by Manjula Peiris <ma...@wso2.com>.
Hi,

I debug the code. What is happening here is Security phase always
invokes at last even you put it before Transport phase. Since soap
action based dispatcher is in Dispatch phase in this situation when it
comes to Rampart actual dispatching has occurred. So this means Axis2/C
always invoke module defined phases after invoking its default phases. I
think we need to fix this. I will raise a JIRA.

Thanks,
-Manjula.

  


On Wed, 2008-05-28 at 14:18 +0530, Manjula Peiris wrote:
> On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
> > Shankar,
> > 
> > I have tested Rampart/C with a soap action(without addressing) and
> > putting the Security phase even before Transport phase and it worked. So
> > I think what is happening in this case is that actual dispatching does
> > not happen from soap action phase dispatcher.
> not happen from soap action based dispatcher.
> 
> >  
> > 
> > -Manjula. 
> > 
> > 
> > On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
> > > Hi,
> > > 
> > > Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
> > > Due to that, if a message is having only soap action (no operation is 
> > > specified in url or no wsa:action is given, so only possible way of 
> > > dispatching is based on soap action) and message is secured, security 
> > > cannot be verified. This is because, rampart needs operation to be 
> > > resolved before verifying the security of the message. If the message is 
> > > having only soap action, then when message comes to rampart, still the 
> > > operation is not resolved.
> > > 
> > > Can somebody confirm soap action based dispatching happening on 
> > > "PreDispatch"? If so, can we introduce another phase "Security" between 
> > > "PreDispatch" and "Dispatch" and install rampart-in-handler to 
> > > "Security" phase? will it cause any problem?  Any reason why 
> > > rampart-in-handler is installed in "PreDispatch" phase rather than 
> > > another phase? (I tried it and it worked)
> > > 
> > > Comments are welcome.
> > > 
> > > Regards,
> > > Shankar.
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Re: soap action based dispatching with rampart

Posted by Manjula Peiris <ma...@wso2.com>.
On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
> Shankar,
> 
> I have tested Rampart/C with a soap action(without addressing) and
> putting the Security phase even before Transport phase and it worked. So
> I think what is happening in this case is that actual dispatching does
> not happen from soap action phase dispatcher.
not happen from soap action based dispatcher.

>  
> 
> -Manjula. 
> 
> 
> On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
> > Hi,
> > 
> > Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
> > Due to that, if a message is having only soap action (no operation is 
> > specified in url or no wsa:action is given, so only possible way of 
> > dispatching is based on soap action) and message is secured, security 
> > cannot be verified. This is because, rampart needs operation to be 
> > resolved before verifying the security of the message. If the message is 
> > having only soap action, then when message comes to rampart, still the 
> > operation is not resolved.
> > 
> > Can somebody confirm soap action based dispatching happening on 
> > "PreDispatch"? If so, can we introduce another phase "Security" between 
> > "PreDispatch" and "Dispatch" and install rampart-in-handler to 
> > "Security" phase? will it cause any problem?  Any reason why 
> > rampart-in-handler is installed in "PreDispatch" phase rather than 
> > another phase? (I tried it and it worked)
> > 
> > Comments are welcome.
> > 
> > Regards,
> > Shankar.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Re: soap action based dispatching with rampart

Posted by Manjula Peiris <ma...@wso2.com>.
On Wed, 2008-05-28 at 14:15 +0530, Manjula Peiris wrote:
> Shankar,
> 
> I have tested Rampart/C with a soap action(without addressing) and
> putting the Security phase even before Transport phase and it worked. So
> I think what is happening in this case is that actual dispatching does
> not happen from soap action phase dispatcher.
not happen from soap action based dispatcher.

>  
> 
> -Manjula. 
> 
> 
> On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
> > Hi,
> > 
> > Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
> > Due to that, if a message is having only soap action (no operation is 
> > specified in url or no wsa:action is given, so only possible way of 
> > dispatching is based on soap action) and message is secured, security 
> > cannot be verified. This is because, rampart needs operation to be 
> > resolved before verifying the security of the message. If the message is 
> > having only soap action, then when message comes to rampart, still the 
> > operation is not resolved.
> > 
> > Can somebody confirm soap action based dispatching happening on 
> > "PreDispatch"? If so, can we introduce another phase "Security" between 
> > "PreDispatch" and "Dispatch" and install rampart-in-handler to 
> > "Security" phase? will it cause any problem?  Any reason why 
> > rampart-in-handler is installed in "PreDispatch" phase rather than 
> > another phase? (I tried it and it worked)
> > 
> > Comments are welcome.
> > 
> > Regards,
> > Shankar.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> 


Re: soap action based dispatching with rampart

Posted by Manjula Peiris <ma...@wso2.com>.
Shankar,

I have tested Rampart/C with a soap action(without addressing) and
putting the Security phase even before Transport phase and it worked. So
I think what is happening in this case is that actual dispatching does
not happen from soap action phase dispatcher. 

-Manjula. 


On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
> Hi,
> 
> Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
> Due to that, if a message is having only soap action (no operation is 
> specified in url or no wsa:action is given, so only possible way of 
> dispatching is based on soap action) and message is secured, security 
> cannot be verified. This is because, rampart needs operation to be 
> resolved before verifying the security of the message. If the message is 
> having only soap action, then when message comes to rampart, still the 
> operation is not resolved.
> 
> Can somebody confirm soap action based dispatching happening on 
> "PreDispatch"? If so, can we introduce another phase "Security" between 
> "PreDispatch" and "Dispatch" and install rampart-in-handler to 
> "Security" phase? will it cause any problem?  Any reason why 
> rampart-in-handler is installed in "PreDispatch" phase rather than 
> another phase? (I tried it and it worked)
> 
> Comments are welcome.
> 
> Regards,
> Shankar.


Re: soap action based dispatching with rampart

Posted by Manjula Peiris <ma...@wso2.com>.
Shankar,

I have tested Rampart/C with a soap action(without addressing) and
putting the Security phase even before Transport phase and it worked. So
I think what is happening in this case is that actual dispatching does
not happen from soap action phase dispatcher. 

-Manjula. 


On Wed, 2008-05-28 at 12:21 +0530, Uthaiyashankar wrote:
> Hi,
> 
> Currently rampart in-handler is called in "PreDispatch" phase in inflow. 
> Due to that, if a message is having only soap action (no operation is 
> specified in url or no wsa:action is given, so only possible way of 
> dispatching is based on soap action) and message is secured, security 
> cannot be verified. This is because, rampart needs operation to be 
> resolved before verifying the security of the message. If the message is 
> having only soap action, then when message comes to rampart, still the 
> operation is not resolved.
> 
> Can somebody confirm soap action based dispatching happening on 
> "PreDispatch"? If so, can we introduce another phase "Security" between 
> "PreDispatch" and "Dispatch" and install rampart-in-handler to 
> "Security" phase? will it cause any problem?  Any reason why 
> rampart-in-handler is installed in "PreDispatch" phase rather than 
> another phase? (I tried it and it worked)
> 
> Comments are welcome.
> 
> Regards,
> Shankar.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org