On 5/11/06, Arash Bijanzadeh <[EMAIL PROTECTED]> wrote:
I want to implement a security layer based on listener. I need to find out wich action in wich class of application would be called in the PhaseListener and the decide if the user allowed to do it or not. After 2 days of googling I couldn't find out how can I get the method would be called at the INVOKE_APPLCATION phase.
Could somebody help me please?
Regards,
Arash

The code that actually decides to invoke a particular action method is the decode() processing for the corresponding Command Button or Command Link component.  It triggers the ultimate call by queueing an ActionEvent sourced by that particular component, which will then get executed (typically at the end of Invoke Application phase) by a default ActionListener provided by the JSF implementation.  This listener's implementation will look up the "action" property of the component, and execute the action method with a method binding _expression_.

Given this, one strategy for implementing a security layer would be to register your own default ActionListener (using a <listener-class> element inside a <listener> element, in a faces-config.xml file) that would be invoked instead of the default one.  If I were doing this, I'd probably follow this kind of a strategy:

* Make my listener implementation class have a constructor that takes
  an ActionListener argument.  This lets me leverage the "decorator pattern"
  approach JSF follows for extension points, because JSF will pass in a
  pointer to the original default ActionListener, so you can delegate to it.

* When the event actually fires, you know which component it is (the origin
  component in the ActionEvent), and can therefore look up the action method
  _expression_ that will be invoked.  You can also get to the FacesContext for
  the current request to examine any other state you need.

* If you decide to allow this invocation, just delegate to the processAction()
  method of the default implementation.  If you want to block it, do something
  else (details here depending on what you want to have happen).

If you decide to try this sort of thing, I'd be very interested in how it works out.  One of the RFEs on our plate for Shale is to add support for a general purpose version of this kind of interceptor, and allow you to specify the processing to perform (before and after the actual action method invocation) with something like Commons Chain or XWork interceptors).  Further discussion of that should take place on the Struts dev list, and/or by making comments on the JIRA issue for it[1].

Craig

[1] http://issues.apache.org/struts/browse/SHALE-149

Reply via email to