Re: [Acegisecurity-developer] PostInvocation and Hibernate Sessions
We utilized a Hibernate interceptor in our solution, though that is only a part of the solution (the interceptor didn't give us everything we needed). - Andy On Wednesday 09 February 2005 09:40 pm, Ben Alex wrote: Gavin Terrill wrote: We recently adopted Acegi Security for one of our enterprise products security requirement, and we will be facing the same issues, so this thread is very useful and timely. Thought out of the blue: instead of mutating the domain objects, would it be possible to wrap them up in a dynamic 'secure' proxy? The proxy would essentially act in the role of a 'caretaker' (http://c2.com/cgi/wiki?CaretakerPattern), preventing access to the secured properties. I guess the downside would be that a dynamic proxy would require your domain objects implementing an interface, which may be cumbersome. Ok, what about utilizing CGLIB to extend the class then (MethodInterceptor)? I have previously played with GCLIBing domain object instances, but that caused some complications with Hibernate. In the end that's what motivated me to write the AspectJ integration, but I was disappointed by the poor incremental compilation reliability in the Eclipse IDE. That's going back probably six months, so it might have improved and using AspectJ is a realistic/viable option for a caretaker-style solution to method invocation. Alternatively, I am just wondering if a Hibernate Interceptor (http://www.hibernate.org/hib_docs/api/net/sf/hibernate/Interceptor.html) might be able to help in this case? It seems to offer the necessary hooks to introspect the object. Ben --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] PostInvocation and Hibernate Sessions
In our model, the lazy approach wouldn't have bought us too much since we have rich clients, meaning that all service invocations happen remotely. One of our goals was to prevent sensitive information from even being transmitted to the client. This means that we would have had to apply the lazy ACL before transmitting the objects to the client anyway. We considered the caretaker approach at first, and I think it is a very good idea. The downside is that it would require you to either define a different access strategy for your domain objects (instead of plain POJO get/set methods) or proxy/AOP your domain objects. This is perfectly acceptable in many cases, and again, is a good solution. In our case it would not have interacted well with other requirements. - Andy On Thursday 10 February 2005 07:58 am, Tim Kettering wrote: I am quite relieved to find that I'm not the only person facing this issue. The discussion so far is quite invaluable and I hope we can continue this thread. I have tried looking at Hibernate Interceptor, but I don't think it is the ideal solution because not all of my objects are obtained by Hibernate (most of them are, but not all). So I need whatever solution that I ultimately go with to work outside of Hibernate. To me, it seems the following conditions are important if we are looking at scrubbing the object instance. 1. ability to apply specific security to variable, or method level granularity. 2. persistence strategy independent. 3. ideally participate in the same transaction as the data load itself to guarantee a consistent version of the data. For the last option - however, if a caretaker pattern is applied, then caretaker implementation itself might choose to take a more lazy-load approach, not actually checking ACL permissions until the method is actually invoked. Is that a feasible option? This particular approach would happen outside the transaction though, so there could be a mismatch in the database object graph and the instanced object. -tim I have previously played with GCLIBing domain object instances, but that caused some complications with Hibernate. In the end that's what motivated me to write the AspectJ integration, but I was disappointed by the poor incremental compilation reliability in the Eclipse IDE. That's going back probably six months, so it might have improved and using AspectJ is a realistic/viable option for a caretaker-style solution to method invocation. Alternatively, I am just wondering if a Hibernate Interceptor (http://www.hibernate.org/hib_docs/api/net/sf/hibernate/Interceptor.html) might be able to help in this case? It seems to offer the necessary hooks to introspect the object. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] PayPal Verification
Dear valued PayPal® member: It has come to our attention that your PayPal® account information needs to be updated as part of our continuing commitment to protect your account and to reduce the instance of fraud on our website. If you could please take 5-10 minutes out of your online experience and update your personal records you will not run into any future problems with the online service. However, failure to update your records will result in account suspension. Please update your records on or before February 12, 2005. Once you have updated your account records, your PayPal® session will not be interrupted and will continue as normal. To update your PayPal® records click on the following link: http://www.paypal.com/cgi-bin/webscr?cmd=_login-run Thank You. PayPal® UPDATE TEAM Accounts Management As outlined in our User Agreement, PayPal® will periodically send you information about site changes and enhancements. Visit our Privacy Policy and User Agreement if you have any questions. http://www.paypal.com/cgi-bin/webscr?cmd=p/gen/ua/policy_privacy-outside --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595_id=14396=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Re: acegi filters and RequestDispatcher include
Hi Sanjiv
We don't use OncePerRequestFilter as it subclasses GenericFilterBean,
which unfortunately is designed for Filters that are wired by web.xml.
The property setting this class performs I suspect would conflict with
Acegi Security Filters, which are wired directly in the IoC container
and proxied using FilterToBeanProxy.
I have just added once per request checking to
FilterSecurityInterceptor. We already perform once per request checking
for other filters as well. It is very easy to do directly, without
needing to subclass OncePerRequestFilter. Hope this sorts out your
performance issue.
I'll cc: the developers list so there is some record of why this change
was made.
Best regards
Ben
-
Sanjiv Jivan wrote:
Ben,
I'm emailing you directly because I'd like to attach screenshots and
the Spring forum doesn't support uploading files. Will update relevant
thread on forum too.
I ran into an issue where the the response time of any page of the
same web app would be less than a couple of seconds under Tomcat 4.x
while under Weblogic 8.1 it would take over a minute. I tried
examining the logs etc but had to use a profiler to get to the root of
the issue. Please find attached profile screenshots of the same page
request under Weblogic and Tomcat.
Contrary to what is mentioned in the thread
http://forum.springframework.org/viewtopic.php?t=1524, Weblogic
executes servlet filters when a RequestDispatcher.include call is
made. Tomcat does not have this behavior.
If you examine the Weblogic screenshot closely, you'll see all kinds
of redundant calls being made primarily triggered do to the fact that
Sitemesh is in the mix which goes on to calling Acegi which in turns
goes on to calling Sitemesh
See
net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor#proceedWithObject
in call stack.
public Object proceedWithObject(Object object) throws Throwable {
FilterInvocation fi = (FilterInvocation) object;
fi.getChain().doFilter(fi.getRequest(), fi.getResponse());
return null;
}
Clearly such response times are unacceptable. While it certainly seems
to be a Weblogic issue, I was wondering if there is any reason the
Acegi filters do no extend
org.springframework.web.filter.OncePerRequestFilter. This would
certainly help reduce the number of times the Acegi filters are
executed and cut down the execution time.
Let me know your thoughts.
Thanks,
Sanjiv
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
