On Wednesday, December 7, 2011 5:03:05 PM UTC+1, Alberto wrote:
>
> Thomas,
>
> Could you explain what do you check at the filter level? How do you
> know if a user is authenticated when you make a GWT-RPC call? It is a
> newbie question, I know, but it is not clear to me if we are
> identifying the user by a query parameter or a HTTP header.
>
We totally delegate authentication to the servlet container (or a servlet
filter if that's really needed), so my AjaxAuthenticationFilter is as easy
as:
public void doFilter(ServletRequest servletRequest, ServletResponse
servletResponse, FilterChain filterChain)
throws IOException, ServletException {
HttpServletRequest request = (HttpServletRequest) servletRequest;
HttpServletResponse response = (HttpServletResponse) servletResponse;
if (request.getUserPrincipal() == null) {
// XXX: HTTP/1.1 requires a WWW-Authenticate header for 401
responses, but in practice it's not needed.
response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
return;
}
filterChain.doFilter(servletRequest, servletResponse);
}
And on the client-side, we check for
com.google.gwt.http.client.Response#getStatusCode() ==
Response.SC_UNAUTHORIZED.
> Thanks
>
> On Dec 7, 4:01 am, Thomas Broyer <[email protected]> wrote:
> > My first app used in-app authentication (because the client wanted to
> bake
> > a "lock screen after 30 minutes of inactivity" in the webapp rather than
> > relying on the OS's built-in mechanism) and it caused us all sorts of
> > issues (disclaimer: at that time, Ray Ryan didn't praise MVP, decoupling
> > via an event bus and those sorts of things, so that was mostly an app
> > architecture issue: clearing caches each time the user logged out so that
> > you don't leak data if you sign in as a different user, and you always
> > forget one cache; we ended up refreshing the page on logout, at the
> expense
> > of throwing out caches of non-sensitive data –and we loaded them using *
> > RESTful* requests to benefit from HTTP caching–).
> >
> > I'm now a big fan of decoupling authentication from the app. That way you
> > can change the authentication mechanism without impact the app. Our
> current
> > app relies on the servlet container for the authentication and roles
> (using
> > <security-constraint>s in the web.xml). We include a
> > <login-config><auth-method>FORM</auth-method>...</login-config> in the
> > web.xml as a default, that we can override (at the servlet-container
> level
> > and/or using a web-override.xml) when we need to use an SSO (such as
> Jasig
> > CAS) or another mean to authenticate users (HTTP Digest, HTTPS with
> > client-certificates). And we use JAAS to actually do the authentication,
> > shipping a default configuration using text files (and a template for
> > connecting to an LDAP server).
> > That way, it's really easy to support deploying the same app in different
> > environments:
> >
> > - form-based login with user credentials and roles in text files
> > (default configuration)
> > - form-based login delegating to an LDAP for authentication
> > - SSO
> >
> > Using JAAS chaining capabilities, we can even authenticate with LDAP or
> > Jasig CAS, and provide roles from a text file.
> >
> > That way, the app becomes easier to code too, as we know the user is
> > authenticated when the page loads, and it won't change for the whole
> > lifetime of the GWT app.
> >
> > We use a dynamic host page<
> http://code.google.com/webtoolkit/articles/dynamic_host_page.html>to
> provide the user name to the GWT app. We do NOT require auth (at the
> > web.xml level) on our AJAX endpoints (RequestFactoryServlet, file-upload
> > servlets; it would be the same for GWT-RPC) and instead handle it in a
> > servlet filter: if there's no authenticated user, return a 4xx status
> code;
> > and on the client-side, handle those cases –user has been logged out by
> > some external mean, not from the GWT app; e.g. session has expired– by
> > asking the user to refresh the page (don't refresh automatically, so they
> > can do some copy/paste to "backup" their unsaved changes).
> >
> > BTW, it seems like it's exactly how Google does authentication on their
> > apps.
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/4z-cu0RoUPEJ.
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-web-toolkit?hl=en.
