I got some ideas from Kent
http://stackoverflow.com/questions/1013032/programmatic-use-of-spring-security
who in turn got some ideas from Spring Security 3 Technical Overview
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/technical-overview.html#d4e689
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.
