Thanks a lot! This gives me a very good head start.
On Dec 7, 10:45 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> 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 <t.br...@gmail.com> 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 post to this group, send email to google-web-toolkit@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.
