An alternative to using a Authentication filter would be to use a Dynamic Proxy that form a central point of access to your public methods (I use this between all my backend layers).
The proxy captures all RPC requests and controls authentication and authorisation. I do send a caller id with every RPC call that is contained in cookie filled by the backend and can only read by the front-end app. The proxy will stripe of the caller id before forwarding the call and will check the correctness of the id. It "overcomes" XSS attacks. I use annotations on the public methods to defines the authentication/ authorization levels and inject the logged in user as an extra argument if indicated in the annotation (completely decoupled methods). Injection of the user is required in a multi threading environment as when you allow access to a method, in the mean time the session might expire and access to a method is incorrectly granted and causes exceptions when the method retrieves the loggedin user. If a loggedin user is required but not present, an login exception will be thrown and picked up by the central front end Service handler that will make a forward to any login url. This will be responsible of performing authentication, inform the backend and return to any url. Hope this give you some idea's. - Ed -- 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.
