Yes, the session cookies wasn't a good option in this case, it was something temporary, I think that I will change it to a cache system like ehcache or jcs. The idea behind is to provide a long lived user authentication and a way to spread the application in a cluster without replication of the session, because the session was just to work as a cache (forget about it). I will try to put the source code in google code today, afterwards I will reply this e-mail with the url to access it.
Thanks On Wed, Dec 2, 2009 at 4:43 PM, Brian Pontarelli <[email protected]>wrote: > Seems a bit complex considering session cookies and JEE session handling is > automatic. Any particular reason you aren't just leveraging the JEE session > directly and storing the current user ID and roles in the session, fetching > them out each request and then handling the AOP based on that? If you are > using a Servlet Session scope, you can by-pass some of the ThreadLocal, > depending on whether or not you need access to the current user in other > scopes or not and if you need access to it in non-guice places (such as JPA > PrePersist, PreUpdate methods). > > -bp > > > On Dec 2, 2009, at 11:35 AM, Eduardo Nunes wrote: > > I've created a simple framework to deal with security. I've created a > interface named SecurityContext. This interface holds the user id and a set > of roles (strings). This class has a Servlet Session scope. The idea of the > session scope is to work on it just as a cache, the valid information I > store on a cookie using blowsfish algorithm, so the application uses the > session as a cache and the timeout of the login you can define inside the > cookie. This framework will be public soon, as soon as I finish the > annotation part to check the current user roles. > Let me know if I was confuse in this explanation, I'm writing it fast not > thinking too much.. > > > On Wed, Dec 2, 2009 at 3:24 PM, Brian Pontarelli <[email protected]>wrote: > >> Yeah, that's the basic gist of it. You definitely don't want to use a >> Singleton for managing the current user, otherwise you can only have a >> single person logged in :) Otherwise, this is pretty much what you need. You >> probably want to make the annotations more flexible as well and I would >> abstract out the whole login and current user process into some type of JEE >> filter system. JCatapult uses a filter type of system via like Spring does >> where it transfers control from the JEE filter into a JCatapult workflow >> chain. That way the workflows can be injected thereby allowing everything >> running inside the web application (less the single JEE filter) to be >> injected. >> >> -bp >> >> >> On Dec 2, 2009, at 9:15 AM, Alexandre Walter Pretyman wrote: >> >> > Hi, >> > >> > I stumbled upon a very interesting post on using AOP on Guice for >> > security. It might be helpful to you: >> > >> > >> http://jpz-log.info/archives/2009/11/04/guice-it-up-or-aop-can-be-made-simple-sometimes/ >> > >> > it is written by an author who identifies himself as jponge, but I >> > couldn't find out his real name. >> > >> > Definitely worth a read. >> > >> > Alex. >> > >> > On Dec 1, 3:04 pm, Brian Pontarelli <[email protected]> wrote: >> >> Spring Security covers the login and web security as well as the object >> level security. >> >> >> >> In terms of the login and web security, I wrote this stuff myself for >> JCatapult. It was pretty simple in general, but the gist is that a Servlet >> filter looks for a specific URL (i.e. /jcatapult-security-check) and then >> uses a well defined class to perform the login. You can also write a URI >> authorizer as well to verify that a user has specific roles and which roles >> can access a specific URI. >> >> >> >> In terms of object level security, this is just a matter of writing a >> bit of AOP to check the users privileges prior to invoking a method. The way >> I handle this that during login, I stuff the User object into the session. >> Each request in my security filter I pull it out and stuff it into a >> ThreadLocal. Then, I just pull the User from the ThreadLocal and inspect it >> in a MethodInterceptor based on an annotation on the method. >> >> >> >> I find it is generally pretty simple to write all this stuff in a >> library that I can re-use across projects. You can check out the code in the >> JCatapult Security library to get an idea of how I did it all: >> >> >> >> >> http://code.google.com/p/jcatapult/source/browse/#svn/jcatapult-secur... >> >> >> >> -bp >> >> >> >> On Dec 1, 2009, at 9:09 AM, severin wrote: >> >> >> >>> What would be the best way to manage security and user roles with >> >>> google guice ? (like spring security for example) >> >> >> >>> Thank you for your answers ! >> >> >> >>> Severin >> >> >> >>> -- >> >> >> >>> You received this message because you are subscribed to the Google >> Groups "google-guice" group. >> >>> To post to this group, send email to [email protected]. >> >>> To unsubscribe from this group, send email to >> [email protected]<google-guice%[email protected]> >> . >> >>> For more options, visit this group athttp:// >> groups.google.com/group/google-guice?hl=en. >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> Groups "google-guice" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> [email protected]<google-guice%[email protected]> >> . >> > For more options, visit this group at >> http://groups.google.com/group/google-guice?hl=en. >> > >> > >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "google-guice" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-guice%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-guice?hl=en. >> >> >> > > > -- > Eduardo S. Nunes > http://enunes.org > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-guice%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > -- Eduardo S. Nunes http://enunes.org -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
