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.
