This is very interesting http://seewah.blogspot.com/2009/02/gwt-and-spring-security.html But comparing See Wah's code, and what I have it looks like mine is less invasive. In fact I haven't had to do anything to my *ServiceImpl classes, except to set them up for Spring. I think the key differences are: - See Wah uses an Exception to let the client know that you are not authenticated - I use a regular page redirect and have to scan for a special token <!-- SECURITY-LOGIN-PAGE -->
- See Wah's code allows you to have protection for your RPC calls - My code allows you to have protection for regular URLs (e.g. / admin.html), and RPC URLs, and method invocations - See Wah's code requires you to authenticate yourself via an RPC call - My code allows you to authenticate yourself via a regular / login.html page, but then once you're in the GWT app, if your session expires you are offered an Ajax style login (like See Wah's). I guess I'm homing in on what I would consider to be my choice of approach. Keep those thousands of responses coming, folks! ;) On Feb 19, 5:32 pm, Paul S <paulsschw...@gmail.com> wrote: > Oops, forgot to mention, don't protect the URL that corresponds to the > RPC login service! > > Like this: > <intercept-url pattern="/**/login.rpc" access="permitAll" /> > <intercept-url pattern="/**/*.rpc" access="isAuthenticated()" /> > > On Feb 19, 5:28 pm, Paul S <paulsschw...@gmail.com> wrote: > > > > > I got some ideas from > > Kenthttp://stackoverflow.com/questions/1013032/programmatic-use-of-spring... > > who in turn got some ideas from Spring Security 3 Technical > > Overviewhttp://static.springsource.org/spring-security/site/docs/3.0.x/refere... > > > I now have a set up that resembles Scenario 4. > > > In my current set up Spring Security is still configured to respond > > with a valid html form at /login.html (with my <!-- SECURITY-LOGIN- > > PAGE --> token hidden in it). So both page requests and XHR Ajax > > requests are subject to Spring Security's declarative set up. Whether > > I arrive at the host page and am not authenticated, or if I > > authenticate and then after my session has timed out I try to call an > > RPC service, I will be met with the /login.html contents as the > > response. Ok, so the only trick now is that in my GWT app if I get an > > InvocationException that equates to Spring Security trying to redirect > > me to the /login.html page then I simply show a nice looking GWT popup > > that looks like this: > > > Sorry, your session seems to have expired > > Username: __________ > > Password: __________ > > Login > > > And when the user clicks Login an RPC call to the server is shot off > > that looks a bit like this: > > > public interface LoginService extends RemoteService { > > boolean login(String username, String password); > > } > > > Note that the boolean it returns isn't the real business here. The > > real business is that we now have an authenticated session on the > > server. The boolean returned just tells our GWT app to hide the popup > > (if true) or keep showing it and tell the user to try log in again (if > > false). That's all. > > > On the server I then have a service implementation that performs the > > login very similarly to what Kent has done: > > > @Override > > public boolean login(String username, String password) { > > > log.debug("Authentication attempt: " + username + " " + > > password); > > > try { > > Authentication request = new > > UsernamePasswordAuthenticationToken( > > username, password); > > Authentication result = > > authenticationManager.authenticate(request); > > > > SecurityContextHolder.getContext().setAuthentication(result); > > } catch (AuthenticationException e) { > > log.info("Authentication failed: " + e.getMessage()); > > return false; > > } > > log.info("Authentication success: " + > > SecurityContextHolder.getContext() > > .getAuthentication()); > > return true; > > } > > > ... where authenticationManager is injected by Spring. To show you > > exactly where I am getting authenticationManager from, here's my > > context configuration: > > > <authentication-manager alias="authenticationManager"> > > <authentication-provider> > > <password-encoder hash="md5" /> > > <jdbc-user-service data-source-ref="dataSource" /> > > </authentication-provider> > > </authentication-manager> > > > I am still undecided whether it is right to have two logins, > > 1. The initial login (traditional web login that moves me from / > > home.html --> /login.html -->(login success)--> /admin.html) > > 2. A secondary login that happens over RPC that provides a quick, > > convenient login via an Ajax popup, such that it doesn't interrupt > > your workflow > > > The second is exactly what I wanted all along! Is the first redundant? > > Or is it just as well to have it. i.e. 1. protects your web app code > > (well the host page), 2. protects the good bits (RPC calls!!!) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
