the previous message was a little bit confuse, the stateless requirement doesn't have anything to do with the JEE stack :P
On Wed, Dec 2, 2009 at 6:38 PM, Eduardo Nunes <[email protected]> wrote: > exactly, the idea is to avoid JEE clustering and the http load balancer. > It's for stateless applications. It's true I have to think in a better way > to implement this local cache. I my last applications I haven't use JEE > stack, at least during the development. I'm using just > jetty+guice+warp-persist+dwr+javascript. One of the requirements was the > statelessness of the application, if I need to temporary save something, I > do it on the client using javascript, if it's a private thing, I do it using > encrypted cookies. All those things can sound strange at first thought but > it improved a lot the development speed due to the fact that everything > integrates with guice, every object is managed by guice. > > > On Wed, Dec 2, 2009 at 6:21 PM, Brian Pontarelli <[email protected]>wrote: > >> Are you specifically trying to avoid JEE clustering and HTTP load balancer >> pinning? >> >> The reason I ask is that you case might not be the norm for most >> applications. And you still need to contend with distributed caching for >> session and credentials. I would abstract out this "cache" as an interface >> and provide the default implementation as the HttpSession. That way folks >> can get up and running easily and you can provide a different (distributed >> cache) implementation for your case. >> >> -bp >> >> >> On Dec 2, 2009, at 1:16 PM, Eduardo Nunes wrote: >> >> 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. >> >> >> -- >> 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 > -- 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.
