spring security (acegi) servlet filter and icefaces  XML
Forum Index -> General Help
Author Message

Joined: 28/Jun/2007 00:00:00
Messages: 5

i'm trying to integrate icefaces and spring security (formerly known as acegi).

spring security uses a servlet filter mechanism to lock down certain urls.

i have used spring security (back when it was still acegi) in the past with some degree of success.

in order to get that to work, i configured the acegi filter in web.xml like so:

     <filter-name>Acegi Filter Chain Proxy</filter-name>
     <filter-name>Acegi Filter Chain Proxy</filter-name>

i needed to specify that the filter was invoked for FORWARD as well as the default,
REQUEST, because myfaces uses "forward" when forwarding from navigating to the "to-view-id" specified in a navigation case in faces-config.xml.

this strategy isn't working for me in icefaces, i think because of it's "direct-to-dom" implementation.

forinstance, here is an excerpt from one of my jspx files:

     <ice:menuItem value="actions">
       <ice:menuItem action="go.page1" value="go.page1" />
       <ice:menuItem action="go.page2" value="go.page2" />

here is an excerpt from my faces-config file:


here is an excerpt from my spring configuration file:

     <intercept-url pattern="/secure/**" access="ROLE_USER"/>
     <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY"/>

(new concise spring security 2.0 syntax)

when using myfaces, if i clicked on the menu item for "go.page2", i would expect to see the acegi filter triggered on a FORWARD, with a url that ended with /secure/page2.jspx as specified in the to-view-id from the navigation-case in faces-config.

when using icefaces, the filter does get triggered, but the url ends with:
/block/send-receive-updates instead of the /secure/page2.jspx required to get spring security to kick in.

i did see an example in the forums showing the use of <redirect/> in the navigation case to force a redirect which does end up passing a url that the spring security filter can work with, but it isn't as efficient as a forward and request context is lost.

so i guess my question is:

is there a way to get icefaces to do a plain old forward with the original url instead of the fancier direct-to-dom forwarding with the /block url?

or can someone convince me that the performance hit and loss of request scope associated with the use of <redirect/> isn't that bad...


Joined: 08/May/2006 00:00:00
Messages: 2989

Have you seen this post?



Joined: 28/Jun/2007 00:00:00
Messages: 5

yes, i saw this. these solutions use <redirect/> in the navigation case, so request scope is lost.
Forum Index -> General Help
Go to:   
Powered by JForum 2.1.7ice © JForum Team