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/-/jNqOyyg_ROAJ. 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.
