Hi, I'm studying how to use Spring Security to secure GWT web apps (I'll check Shiro in the future so I can't compare the two solutions).
I'm working backed by a open source github repo and you can take a look to it: https://github.com/cristcost/springsec however it is a work in progress, where the GWT code is still all missing :-) and may require some tricky modification for you to build it (it requires the parent of another project of mine which is not updated, it is a maven project and also is thought to be deployed in Karaf and so it is not a standard web app, but i think that there good hints and I'm available to answer questions about it). The main point to note about my solution for using Spring Security is that it has to be a Spring Web Application and used Spring MVC. In the end like this approach as I intend to make a light usage of Spring MVC dedicated only to generation of baking html pages. I want to use Spring Security to manage authentication outside of GWT (let's say in an old Web 1.0 fashion with old plain html forms) and then work on with authorization annotations directly on the service like you can see on this example of code: https://github.com/cristcost/springsec/blob/master/src/main/java/net/cristcost/study/AnnotatedServiceImpl.java If you intend to proceed in this direction, the main issue I've solved has been to declare a simple HttpServlet and publish it over Spring MVC so it can get "Secured": this is not well documented (you only find easily how to add Spring MVC controllers or the Spring servlets like classes of type org.springframework.web.HttpRequestHandler! But a GWT RPC service implements an HttpServlet!) but in the end I found a simple solution that is registering a SimpleServletHandlerAdapter bean (as in https://github.com/cristcost/springsec/blob/master/src/main/webapp/WEB-INF/spring/beans-mvc.xml) and then map it to an URL managed by Spring MVC DispatcherServlet (as you can see in https://github.com/cristcost/springsec/blob/master/src/main/webapp/WEB-INF/spring/beans.xml ). The study is not done yet and up to now I've secured only a standard HttpServlet (or to be more precise, I've secured an indipendent POJO which is used by a standard HttpServlet). I'm actually preparing a GWT application to add to the project and then start testing securing a RPC GWT Service (that is my final goal). For simplicity however I will put pre-compiled JavaScript code only in the project so I can focus on the server side. If anyone is interested I'm glad to give free support in exchange for feedback :-) Cristiano Il giorno giovedì 5 dicembre 2013 21:52:14 UTC+1, doctra...@gmail.com ha scritto: > > Hi, > > I'm trying to implement a login service whereby the user submits their > username and password to the app server (using RPC or RF, it doesn't really > matter). Then on the server side, once I've verified that the credentials > are valid, I need to: > > 1. Call a loginDAO and record the login to persistence, then > 2. Set some sort of session variable and/or cookie that can be used on > subsequent requests to authenticate the user against > 3. On such subsequent requests, check for the existence of the cookie > and validate it; > 4. Then, if they are inactive for a period of time, or they want to > log out, I need a way to clear the cookie or end the session somehow > > I can handle #1 above all on my own, but I'm struggling with #2 - #4. In > older versions of GWT I read that I could implement my own UserInformation > (and then configure the web.xml to accept this impl as a context param) > like so: > > public class MyUserInformation implements UserInformation { > @Override > public boolean isUserLoggedIn() { > HttpServletRequest request = > RequestFactoryServlet.getThreadLocalRequest(); > > // Now query the request for the presence of a cookie or session > var, etc. and return true or false accordingly. > } > } > > *However*, as of 2.5.1 (the version I'm using) this class has been > removed altogether (or so it seems). So I ask, what is the proper way to > implement GWT authentication now-a-days? Is it still session/cookie based? > If so, what does it look like, for both the login and the logout? Thanks! > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
