Thanks for your quick response and elaborate answer, Braheem!
I've tried a servlet-filter, but that didn't work for me since my
security constraint protects EVERY possible url within my app, see
following URL-pattern:
<security-constraint>
<web-resource-collection>
..
<url-pattern>/*</url-pattern>
I guess I'll have to make this more fine grained, and put the servlet
filter servlet in an unprotected area.
Ciao,
Willem
On Jun 20, 12:01 pm, Braheem Sikiru <[email protected]> wrote:
> Hello
> There have been many approaches to securing GWT applications, I think it all
> depends on your application workflow. But an approach similar to yours that
> i'm used to follows:
> - Create a servlet filter to filter requests for the GWT module servlets.
> Then in the doFilter() method do something like ...
> HttSession session = request.getSession(false); // get the session
> attached to request
> if(session == null) { // the case if client is not logged in
> ression.sendError(HttpServletResponse.SC_UNAUTHORIZED);
> } else {
> chain.doFilter(request, response); // pass request on to the
> GWT servlets
> }
> - Next create a custom AsyncCallback handler for the client side wherein the
> onFailure() method does something like this ..
> void doFailure(Throwable t) {
> try {
> throw t;
> } catch (IncompatibleRemoteServiceException e) {
> // this client code is not compatible with the server refresh the
> browser to download new one
> Window.Location.reload();
> } catch (StatusCodeException e) {
> // the call didn't complete cleanly
> switch (e.getStatusCode()) {
> case 401: // Authentication required; reload the whole page
> so server can enforce login
> Window.Location.reload();
> break;
> default:
> // do other tests or pass on to an abstract method so you
> can do more localized processing
> }
> } catch (Throwable e) {
> // shouldn't get here though ...
> }
> }
> then you can use the custom AsyncCallback handler in other RPC requests of
> the application
> However, this approach appears to require some application design issues
> - the URL (especially the history tokens) you choose SHOULD be mapped to
> known application states, so that the application can appear to return to
> where it was before the Window.Location.reload() call.
> - the host page of the GWT module SHOULD be placed behind a security
> constraint
> This way i've been able to use container managed security and standard
> servlet security annotations in my application
> Just another way of achieving the same result:-)
> Cheers
> [email protected]:In my GWT application MyApp I'm using
> container managed security
> (logon through html form with
> action=j_security_check and input elements j_username and j_password).
> Works fine except
> when the application times out: the container doesn't allow the RPC
> service to be executed anymore on the server, so it throws back the
> html of the logon-form. But the client side RPC code has no 'solid'
> way of detecting this.
> Currently I've implemented it as follows: in the onFailure method,
> check if it's an InvocationException, then check if it contains a bit
> of html that's in the logon-page.
> If yes, then redirect to the start page of my app.
> AsyncCallback<Void> callback = new AsyncCallback<Void>()
> {
> public void onFailure(Throwable caught)
> {
> if ( (caught instanceof InvocationException)
> && (caught.getMessage().contains("<html><head><title>MyApp
> Logon</title></head>") ))
> {
> Window.Location.assign("MyApp.html");
> }
> else
> {
> ..
> Is there a more proper way of doing this?
> Regards,
> Willem
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
