You could check it like this: Normally my RPC calls look something like this: modifyDeclarationOfLoggedInMember(DeclarationDto member);
Notice that you don't send the logged in member along as it's known in the backend. The logged in member is present in the session (at least his id). If the is is present, it's a valid request -> authentication: this can be done in a servlet filter. Besides that you have to do some sort of authorization if required (is the allowed to modify the declaration in the call above). - Ed On Wed, Dec 7, 2011 at 5:03 PM, Alberto <[email protected]> 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. > > 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 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. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. 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.
