axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Detelin Yordanov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2-4493) Disengagement of module which is not globally engaged removes module's handlers from the global phase chain
Date Mon, 14 Sep 2009 13:25:57 GMT

    [ https://issues.apache.org/jira/browse/AXIS2-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754973#action_12754973
] 

Detelin Yordanov commented on AXIS2-4493:
-----------------------------------------

Yes, you are right. Modules which add operations to the service must be handled with care
- these operations must  be removed on module disengagement, but only if the module is not
engaged on any other operation in the service. 
Because if other operations have this module engaged they will require its special operations
to be available on the service.

> Disengagement of module which is not globally engaged removes module's handlers from
the global phase chain
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2-4493
>                 URL: https://issues.apache.org/jira/browse/AXIS2-4493
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.5
>         Environment: Tomcat  5.5.26, Axis2 war 1.4.1/1.5, Rampart 1.4
>            Reporter: Detelin Yordanov
>         Attachments: patch.txt, ut-secured-service1.aar, ut-secured-service1.zip, ut-secured-service2.aar
>
>
> We have an Axis2 1.4.1 runtime, which has Rampart module deployed, but not globally engaged
(using the default axis2.xml from axis2.war)
> We have two services, both of them are secured (Rampart is engaged for each service by
using <module ref="rampart"/> in services.xml). 
> When Rampart is disengaged on one of the services, it happens that the Rampart handler
is removed from the security phase. This practically disables access to the other secured
service, since secured service requests are not handled by Rampart anymore (no handler in
security phase) and when attempting to invoke it, Axis2 throws a mustUnderstand check failed
for the security header:
> [ERROR] Must Understand check failed for header http://docs.oasis-open.org/wss/
> 004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd : Security
> We examined the module disengage logic, and it seems that the handler removal takes place
in AxisOperation#onDisengage(AxisModule module). The code there would remove module's handlers
from global chains if the module is not engaged on service nor on gloabal level. What is the
reason for this, and what if the module is engaged on another service (as in our case)?
> I attach two simple services you can simulate this with. They are based on Rampart's
Tomcat policy sample, but are secured
> with a simple Username supporting token.
> Steps to simulate the problem:
> 1. Deploy both services to Axis2 1.4.1/1.5 webapp having Rampart deployed (but not engaged
in axis2.xml)
> 2. Using the web administration intefrace, disengage Rampart module on one of the services
> 3. Try to invoke the other service using the Client.java class (or by any other means)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message