Mule

Revise Lazy Init for Security Filters

Details

  • User impact:
    Low
  • Effort points:
    0.5
  • Similar Issues:
    MULE-5723 Https transport documents acegi security filter
    MULE-197 Add WS-Security endpoint filter
    MULE-4916 custom-security-filter should allow setting properties and referencing a bean
    MULE-4322 Custom security filter element missing
    MULE-5836 Cannot use message-filter, idempotent-message-filter, idempotent-secure-hash-message-filter and combine-collections-transformer as global elements
    MULE-2 Components are always lazy loaded
    MULE-2106 Replace xsi:type with Substitution for Security Configuration
    MULE-3383 Serving out WSDL over the VM protocol with CXF does not work
    MULE-4208 Component authorization/method security not working in Mule 2.2 anymore.
    MULE-2825 Configuration of inbound XFire (and Axis) endpoint with WS-Security is not very logical

Description

The initialise method of AbstractEndpointSecurityFilter is called after the object is created and populated via Spring, but before it receives an endpoint (which is set from within the endpoint, when the filter is injected into the endpoint, which occurs after this object is created and initialised).

This means that when initialise() is called, the endpoint is not known. So the endpoint type cannot be checked. So the initialisation code which requires the endpoint type must be postponed until after the endpoint is set. At the moment we use lazy initialisation - the method lazyInit() is not called until the filter is used (by which point the endpoint should be set). Another alternative would be to initialise when the endpoint is set.

Anyway, Ross asked for this to be noted in an issue here for later consideration.

Issue Links

Duplicate
 

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
andrew cooke added a comment - 25/Jun/07 10:46 AM

Andrew P mentions that there is a "model complete" event of some kind that is available to Mule components. This would probably be the best way to do initialisation like this.

Show
andrew cooke added a comment - 25/Jun/07 10:46 AM Andrew P mentions that there is a "model complete" event of some kind that is available to Mule components. This would probably be the best way to do initialisation like this.
Hide
Permalink
andrew cooke added a comment - 27/Jun/07 09:25 AM

That event was related to the old mule manager (or whatever). We probably need a completely new event.

See also MULE-1957 which needs similar re-working.

Show
andrew cooke added a comment - 27/Jun/07 09:25 AM That event was related to the old mule manager (or whatever). We probably need a completely new event. See also MULE-1957 which needs similar re-working.
Hide
Permalink
Daniel Feist added a comment - 14/Feb/08 08:21 PM

Started looking into this, I think the MuleContext "start" phase is equivalent to the the "model complete" in 1.4, at least for cases like this.

The problem that prevents this implementation is the fact that securityFilters are prototypes in spring, so when the "start" lifecycle phase attempts to "start" the security filter, what the registry returns is a new "prototype" instance which of course is not what is wanted, and has the endpoint in null.

Looking at the abstract bean definition parser classes it seems singleton=false is the default. shouldn't this default be true, give than we are using spring as a "registry" in almost all cases i know of. Alternatively i suppose we can implement an abstract SecurityEndpointFilter BDP which sets singleton=true and extend that? thoughts?

Show
Daniel Feist added a comment - 14/Feb/08 08:21 PM Started looking into this, I think the MuleContext "start" phase is equivalent to the the "model complete" in 1.4, at least for cases like this. The problem that prevents this implementation is the fact that securityFilters are prototypes in spring, so when the "start" lifecycle phase attempts to "start" the security filter, what the registry returns is a new "prototype" instance which of course is not what is wanted, and has the endpoint in null. Looking at the abstract bean definition parser classes it seems singleton=false is the default. shouldn't this default be true, give than we are using spring as a "registry" in almost all cases i know of. Alternatively i suppose we can implement an abstract SecurityEndpointFilter BDP which sets singleton=true and extend that? thoughts?
Hide
Permalink
andrew cooke added a comment - 15/Feb/08 07:03 AM

if start will work that sounds good - i think what andrew p might have been referring to was an event rather than a lifecycle call (to be honest it's not clear why both mechanisms exist)? lifecycle calls are easier because you don't have to register to receive them.

Show
andrew cooke added a comment - 15/Feb/08 07:03 AM if start will work that sounds good - i think what andrew p might have been referring to was an event rather than a lifecycle call (to be honest it's not clear why both mechanisms exist)? lifecycle calls are easier because you don't have to register to receive them.

People

Vote (0)
Watch (0)

Dates

  • Created:
    25/Jun/07 08:56 AM
    Updated:
    07/Nov/08 02:15 PM
Atlassian JIRA (v4.2#587) | Report a problem
Powered by a free Atlassian JIRA open source license for MuleForge. Try JIRA - bug tracking software for your team.