[ 
https://issues.apache.org/jira/browse/AXIS2-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amila Chinthaka Suriarachchi updated AXIS2-4493:
------------------------------------------------

    Attachment: patch.txt

can you test with the attached patch?

I think this similar problem can happen with operation disengage as well.

//removing operations added at the time of module engagemnt
        HashMap<QName, AxisOperation> moduleOperations = module.getOperations();
        if (moduleOperations != null) {
            Iterator<AxisOperation> moduleOperations_itr = 
moduleOperations.values().iterator();
            while (moduleOperations_itr.hasNext()) {
                AxisOperation operation = moduleOperations_itr.next();
                service.removeOperation(operation.getName());
            }
        }

it removes the added module operations if one operation get disengaged. 

> 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.

Reply via email to