This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Method call why not be intercepted by MethodSecurityIntercepPage Title Module

Method call why not be intercepted by MethodSecurityIntercep

The application is based on an old architecture, business method is called in jsp code, so I write a Spring bean as a wrapper
of the business method code, e.g. call PositionManager.getPositions in SecurityPositionManager.getPositions. See the code
example below.

With contacts example as the template, I changed something, it works except that method calls aren't intercepted by MethodSecurityInterceptor.

Because I'm a newbie to Spring & AcegiSecurity,maybe I don't really understand some idea.

The ROLE_USER is the most basic type of authorization - role-based access control. The remaining configuration attributes (ACL_CONTACT_ADMIN, AFTER_ACL_READ etc) provide ACL services. ACL services relate to not only the method invocation but also to the domain object passed to or returned from the method invocation. Looking at your debug messages, it would seem you're still using the sample data in terms of defining the ACLs that apply to different invocations.

All-in-all I think you need to spend a little time with the reference manual. I updated it last night, so checkout from CVS and it will discuss the ACL capabilites in a lot better detail. Sorry to refer you back to the manual, but given I just wrote all this last night - and it's fairly comprehensive in detail - I think you'll get more value from a quick read there than reading a brief summary again.

If you modify your configuration but it still doesn't work, please post your new configuration and I'll be happy to help. In the first instance I'd urge you to not try and use the ACL capabilities - just use the RoleVoter until you've got a reasonable feel for how Acegi Security works.

Comment

If you're needing to filter domain object instances, as seems to be the case with "getPositions", you'll need ACL security. In this case you'll need to have a configuration similar to your existing configuration. Please post the contents of your two ACL tables, as I think that'll show what the problem is.

Comment

This is a hard one to help you with given the size of stack traces etc and the number of messages. So, let's just focus on getting your getPositions method working initially.

Your MethodSecurityInterceptor appears properly configured for getPositions. Requiring ROLE_USER will force the user to be logged in, and requiring AFTER_ACL_COLLECTION_READ will ensures every Collection element returned by the getPermissions has a "read" permission.

I'm assuming you're happy using the sample users. As shown by acl_permission, "scott" is the only user who has access to acl_object_identity.id = 100, which is "com.xxx.jaidwapfactory.position.concrete.Position Impl:aaron8tang". Something troubling me is the RHS of the colon, which is "aaron8tang". If the PositionImpl.getId() returns a String, "aaron8tang", this is correct. However, identity properties are typically Integer or Long objects with no business meaning, so I'm wondering if this is correct. If your PositionImpl.getId() returns say 34, the acl_object_identity row should be "com.xxx.jaidwapfactory.position.concrete.Position Impl:34".

Could you give your application a try again with the above in mind, and post any debug messages produced by the net.sf.acegisecurity.acl package and subpackages, along with any updates you made to the database tables.

&#91;ERROR,FilterSecurityInterceptor,http-8080-Processor25&#93; ServletException
org.apache.jasper.JasperException
at org.apache.jasper.servlet.JspServletWrapper.service&#40;JspServletWrapper.java&#58;373&#41;
at org.apache.jasper.servlet.JspServlet.serviceJspFile&#40;JspServlet.java&#58;295&#41;
at org.apache.jasper.servlet.JspServlet.service&#40;JspServlet.java&#58;245&#41;
at javax.servlet.http.HttpServlet.service&#40;HttpServlet.java&#58;802&#41;
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;237&#41;
at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
at net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke&#40;FilterSecurityInterceptor.java&#58;77&#41;
at net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter.doFilter&#40;SecurityEnforcementFilter.java&#58;169&#41;
at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter&#40;FilterToBeanProxy.java&#58;105&#41;
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;186&#41;
at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
at net.sf.acegisecurity.ui.AbstractIntegrationFilter.doFilter&#40;AbstractIntegrationFilter.java&#58;172&#41;
at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter&#40;FilterToBeanProxy.java&#58;105&#41;
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;186&#41;
at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
at net.sf.acegisecurity.ui.AbstractProcessingFilter.doFilter&#40;AbstractProcessingFilter.java&#58;391&#41;
at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter&#40;FilterToBeanProxy.java&#58;105&#41;
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;186&#41;
at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
at org.apache.catalina.core.StandardWrapperValve.invoke&#40;StandardWrapperValve.java&#58;214&#41;
at org.apache.catalina.core.StandardContextValve.invoke&#40;StandardContextValve.java&#58;178&#41;
at org.apache.catalina.core.StandardHostValve.invoke&#40;StandardHostValve.java&#58;126&#41;
at org.apache.catalina.valves.ErrorReportValve.invoke&#40;ErrorReportValve.java&#58;105&#41;
at org.apache.catalina.core.StandardEngineValve.invoke&#40;StandardEngineValve.java&#58;107&#41;
at org.apache.catalina.connector.CoyoteAdapter.service&#40;CoyoteAdapter.java&#58;148&#41;
at org.apache.coyote.http11.Http11Processor.process&#40;Http11Processor.java&#58;825&#41;
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection&#40;Http11Protocol.java&#58;731&#41;
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket&#40;PoolTcpEndpoint.java&#58;526&#41;
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt&#40;LeaderFollowerWorkerThread.java&#58;80&#41;
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run&#40;ThreadPool.java&#58;684&#41;
at java.lang.Thread.run&#40;Thread.java&#58;595&#41;
&#91;ERROR,FilterSecurityInterceptor,http-8080-Processor25&#93; RootCause
java.util.NoSuchElementException
at java.util.HashMap$HashIterator.nextEntry&#40;HashMap.java&#58;790&#41;
at java.util.HashMap$KeyIterator.next&#40;HashMap.java&#58;823&#41;
at org.apache.jsp.secure.position_005fbrowse_jsp._jspService&#40;org.apache.jsp.secure.position_005fbrowse_jsp&#58;105&#41;
at org.apache.jasper.runtime.HttpJspBase.service&#40;HttpJspBase.java&#58;99&#41;
at javax.servlet.http.HttpServlet.service&#40;HttpServlet.java&#58;802&#41;
at org.apache.jasper.servlet.JspServletWrapper.service&#40;JspServletWrapper.java&#58;325&#41;
at org.apache.jasper.servlet.JspServlet.serviceJspFile&#40;JspServlet.java&#58;295&#41;
at org.apache.jasper.servlet.JspServlet.service&#40;JspServlet.java&#58;245&#41;
at javax.servlet.http.HttpServlet.service&#40;HttpServlet.java&#58;802&#41;
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;237&#41;
at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
at net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke&#40;FilterSecurityInterceptor.java&#58;77&#41;
at net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter.doFilter&#40;SecurityEnforcementFilter.java&#58;169&#41;
at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter&#40;FilterToBeanProxy.java&#58;105&#41;
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;186&#41;
at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
at net.sf.acegisecurity.ui.AbstractIntegrationFilter.doFilter&#40;AbstractIntegrationFilter.java&#58;172&#41;
at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter&#40;FilterToBeanProxy.java&#58;105&#41;
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;186&#41;
at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
at net.sf.acegisecurity.ui.AbstractProcessingFilter.doFilter&#40;AbstractProcessingFilter.java&#58;391&#41;
at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter&#40;FilterToBeanProxy.java&#58;105&#41;
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;186&#41;
at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
at org.apache.catalina.core.StandardWrapperValve.invoke&#40;StandardWrapperValve.java&#58;214&#41;
at org.apache.catalina.core.StandardContextValve.invoke&#40;StandardContextValve.java&#58;178&#41;
at org.apache.catalina.core.StandardHostValve.invoke&#40;StandardHostValve.java&#58;126&#41;
at org.apache.catalina.valves.ErrorReportValve.invoke&#40;ErrorReportValve.java&#58;105&#41;
at org.apache.catalina.core.StandardEngineValve.invoke&#40;StandardEngineValve.java&#58;107&#41;
at org.apache.catalina.connector.CoyoteAdapter.service&#40;CoyoteAdapter.java&#58;148&#41;
at org.apache.coyote.http11.Http11Processor.process&#40;Http11Processor.java&#58;825&#41;
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection&#40;Http11Protocol.java&#58;731&#41;
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket&#40;PoolTcpEndpoint.java&#58;526&#41;
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt&#40;LeaderFollowerWorkerThread.java&#58;80&#41;
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run&#40;ThreadPool.java&#58;684&#41;
at java.lang.Thread.run&#40;Thread.java&#58;595&#41;

3.It works!
Because my application is based on so-called Model 1 architecture, maybe there is something special somewhere.
Your Spring framework based contacts application runs pretty well without such modification.

Thanks for your great patience to help me, Ben!

By the way, in BasicAclEntryAfterInvocationCollectionFilteringPro vider's decide method, I make a copy of returnedObject,
and then remove items from the copy instead, not from returnedObject directly. Under some circumstance, returnedObject
maybe be the only copy of business data. Perhaps in this case, I shouldn't be so lazy to reuse the reference impl, but to write my own AfterInvocationProvider.

Comment

By the way, in BasicAclEntryAfterInvocationCollectionFilteringPro vider's decide method, I make a copy of returnedObject,
and then remove items from the copy instead, not from returnedObject directly. Under some circumstance, returnedObject
maybe be the only copy of business data. Perhaps in this case, I shouldn't be so lazy to reuse the reference impl, but to write my own AfterInvocationProvider.

Or have your business method itself perform a clone, which would seem the safest place to do it.