Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: soap action based dispatching with rampart
From: Manjula Peiris <manjula@wso2.com>
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
Cc: rampart-c-dev@ws.apache.org
In-Reply-To: <483D28CF.6080703@wso2.com>
References: <483D00FF.6000300@wso2.com>  <1211964340.6224.16.camel@manjula>
	 <1211964514.6224.19.camel@manjula> <1211965660.6224.26.camel@manjula>
	 <483D2CE7.8030507@wso2.com>  <483D28CF.6080703@wso2.com>
Content-Type: text/plain
Date: Wed, 28 May 2008 21:36:01 +0530
Message-Id: <1211990761.6093.11.camel@manjula>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


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