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.
Thanks On Dec 7, 4:01 am, Thomas Broyer <t.bro...@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.
