Thanks for your feedback. I can see where your approach comes from given the mentioned scenario.
However, I neither do want to check for proper i.e. still valid authentication in all of my RemoteServiceServlet methods nor would I want my GWT application tie to an authentication mechanism at all. I'd like one and the same GWT app to work in a secure environment and in a "regular" environment - without changing the code. Those were my reasons to go with the container-managed-security-approach. On Mar 5, 12:47 am, Jason Essington <[email protected]> wrote: > The problem with jumping ahead of the RemoteServiceServlet for your > authentication is that you don't have a good way to communicate to GWT > that there was an authentication exception. > > I tend to do my JAAS login inside the RemoteServiceServlet where I can > throw a checked AuthenticationException which I can in turn handle > gracefully on the client side. > > consider this scenario: > > User loads a rather large cash worksheet that he needs to fill, the > user begins filling the worksheet, then takes a break, and returns to > complete the worksheet. This user then submits the completed worksheet. > > Now, with the previously mentioned technique, the session is checked > before the request is deserialized and the server notices that the > session has expired, and throws an authentication exception. The > client recieves that exception in the onFailure() method of the > callback and takes appropriate action to have the user reauthenticate. > once that process is successful, the client application can resubmit > the original request, and the user has not lost any of his work. > > If you use the default form based the world just stops, the user is > forced to reauthenticate outside the scope of the application, and his > progress is lost. This really aggravates customers by the way. > > -jason > > On Mar 4, 2009, at 7:30 AM, marcelstoer wrote: > > > > > Hhhmm, the community being quiet can mean a lot of things...none are > > really positive. > > > Was I talking about some dark GWT corners where no stable/proper > > solutions exist? > > Or is there simply "no right way" to solve my problem, but rather many > > potential solutions that all have their flaws? > > > On Feb 28, 8:26 am, marcelstoer <[email protected]> wrote: > >> Is there some consensus or best practice in the GWT community as for > >> how to deal with session timeout and container managed security? > >> There > >> are some pointers if you search for this subject, but some of the > >> ideas are wild... > > >> In my case I use the Servlet container's built in security features > >> for authentication as described in the Servlet specification. Hence, > >> in my web.xm I protect access to the GWT application like so: > > >> <security-constraint> > >> <web-resource-collection> > >> <web-resource-name>my app</web-resource-name> > >> <url-pattern>/app/*</url-pattern> > >> <http-method>GET</http-method> > >> <http-method>POST</http-method> > >> <http-method>PUT</http-method> > >> <http-method>DELETE</http-method> > >> </web-resource-collection> > >> <auth-constraint> > >> <role-name>*</role-name> > >> </auth-constraint> > >> </security-constraint> > > >> <login-config> > >> <auth-method>FORM</auth-method> > >> <form-login-config> > >> <form-login-page>/public/login.jsp</form-login-page> > >> <form-error-page>/public/login.jsp?retry=true</form-error-page> > >> </form-login-config> > >> </login-config> > > >> <security-role> > >> <role-name>*</role-name> > >> </security-role> > > >> So, the application (host/bootstrap page, RPC Servlet, etc.) is in > >> the > >> "app" folder and the login form (login.jsp) is in the "public" > >> folder. > >> This works flawlessly except for the session timeout use case. > >> The application sends an RPC request to /app/AppServlet, the Servlet > >> container requires authentication because the session had timed out > >> and dutifully *forwards* to the login page. Hence, the result of the > >> request is not some RPC/JSON/XML object as expected by the client but > >> the login page HTML structure. The client simply isn't prepared for > >> that and freezes i.e. doesn't do anything. > > >> I believe that on the server side everything is set up correctly. If > >> the session timed out the requests don't even reach the RPC Servlet > >> because it's intercepted by the container, fine. > > >> But how do you deal with this in the client? > >> Should one write some custom AsyncCallback class that handles the > >> reponse sent by the container? > > >> Thanks for your feedback. > >>Marcel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
