Re: Dealing with session timeout and container managed security
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 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: > > > > my app > /app/* > GET > POST > PUT > DELETE > > > * > > > > > FORM > > /public/login.jsp > /public/login.jsp?retry=true > > > > > * > > > 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 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 -~--~~~~--~~--~--~---
Re: Dealing with session timeout and container managed security
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 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: >> >> >> >> my app >> /app/* >> GET >> POST >> PUT >> DELETE >> >> >> * >> >> >> >> >> FORM >> >> /public/login.jsp >> /public/login.jsp?retry=true >> >> >> >> >> * >> >> >> 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 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 -~--~~~~--~~--~--~---
Re: Dealing with session timeout and container managed security
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 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 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: > > >> > >> > >> my app > >> /app/* > >> GET > >> POST > >> PUT > >> DELETE > >> > >> > >> * > >> > >> > > >> > >> FORM > >> > >> /public/login.jsp > >> /public/login.jsp?retry=true > >> > >> > > >> > >> * > >> > > >> 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 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 -~--~~~~--~~--~--~---
Re: Dealing with session timeout and container managed security
we use server push for session time out and it works really great! On Feb 28, 1:26 am, marcelstoer 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: > > > > my app > /app/* > GET > POST > PUT > DELETE > > > * > > > > > FORM > > /public/login.jsp > /public/login.jsp?retry=true > > > > > * > > > 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 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 -~--~~~~--~~--~--~---
Re: Dealing with session timeout and container managed security
What do you mean by "server push"? Could you maybe elaborate on your approach a little, thanks. On Mar 6, 5:11 pm, Rakesh wrote: > we use server push for session time out and it works really great! > > On Feb 28, 1:26 am, marcelstoer 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: > > > > > > > my app > > /app/* > > GET > > POST > > PUT > > DELETE > > > > > > * > > > > > > > > > FORM > > > > /public/login.jsp > > /public/login.jsp?retry=true > > > > > > > > > * > > > > > 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 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 -~--~~~~--~~--~--~---
Re: Dealing with session timeout and container managed security
Hi All, I use a timer in the gwt app to ping the server so that the session doesn't expire. If the user loggs out or closes the browser window the timer stops pinging the server and the session times out. This has its flaws for sure! For instance the user logged in at a public computer and forgets to close the browser window or log out. But at least I don't need to catch failures in every rpc/ajax call to try to figure out if the session expired. I suppose people could call this 'server push' but I generally have issues with the terms 'push and pull' in computer architecture. More comments are in this class; http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/BaseController.java?view=markup Cheers, Scott On Mar 7, 3:31 am, marcelstoer wrote: > What do you mean by "server push"? Could you maybe elaborate on your > approach a little, thanks. > > On Mar 6, 5:11 pm, Rakesh wrote: > > > we use server push for session time out and it works really great! > > > On Feb 28, 1:26 am, marcelstoer 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: > > > > > > > > > > my app > > > /app/* > > > GET > > > POST > > > PUT > > > DELETE > > > > > > > > > * > > > > > > > > > > > > > FORM > > > > > > /public/login.jsp > > > /public/login.jsp?retry=true > > > > > > > > > > > > > * > > > > > > > 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 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 -~--~~~~--~~--~--~---
Re: Dealing with session timeout and container managed security
I handle this in the following way: Use a servlet filter to check the status of the authentication. Check the URL requested (this can be done using a specific kind of filter mapping and initialization parameter), if it is a GWT request then send back an encoded exception that the GWT client will understand. If it is a request for a 'normal' html/jsp/etc then forward to an error page. On Feb 28, 3:26 am, marcelstoer 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: > > > > my app > /app/* > GET > POST > PUT > DELETE > > > * > > > > > FORM > > /public/login.jsp > /public/login.jsp?retry=true > > > > > * > > > 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 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 -~--~~~~--~~--~--~---
