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: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
