Session Management in GWT

1,898 views
Skip to first unread message

Santosh

unread,
Jun 21, 2012, 2:54:34 AM6/21/12
to Google Web Toolkit
I have few basic questions on session management in GWTP.

1. Now, we create a new session when the user logs in to application.
Now, I can open a browser and type in the app url with a token
directly without logging in. It will render the UI page to user
without any checks. Now, we have session checks in server side. So if
the UI page make s a server call on rendering then only, I will get to
know session is not valid and i can redirect him to login page. But,
how do we handle the cases where UI page does not have any server side
logic and user directly paste the URL with that token.
Do I have to make a server call on every page request from GWTP
presenter just to check session is valid? or do we have any other
approaches to it?

2. I am not passing any explicit session id param from GWT Client to
server. Its only the JSessionId getting passed automatically from
browser to server. We just do request.getSession() in server and see
if it is null or not(Not logged in if null). So I hope we dont have
any security issues with this. Please confirm.

3. With GWT client running on android and server side logic exposed as
Restful Web services using Jersey, how do we maintain session because
Restful WS are stateless. Now how do we achieve user session in this
case?

Nikola Markovic

unread,
Jun 21, 2012, 3:15:46 AM6/21/12
to google-we...@googlegroups.com
1. Keep your session id on the client aswell. That way you know if you're logged in, or not, on the client side. User can type in an URL and if the user isn't logged in, you can just switch to a login activity.

Santosh

unread,
Jun 21, 2012, 3:33:10 AM6/21/12
to Google Web Toolkit
In this way, you need to get hold of the server generated session id
in client first time and use it to check whether session id stored is
null or not. Just wanted to check, whether it would be a best practice
solution?

Santosh

unread,
Jun 21, 2012, 3:34:44 AM6/21/12
to Google Web Toolkit
Also, any ideas on question 2 and 3?

Ümit Seren

unread,
Jun 21, 2012, 10:30:28 AM6/21/12
to google-we...@googlegroups.com
1.) 

On the backend (servelet/JSP) you can check if the the user is authenticated and if he is you can render it as a javascript variable (var user={'name':'John','role':'ADMIN'} in your html/jsp host page. 
Then in your GWT client app you can read this variable. This way you don't need any backend call to check if the user is logged in and it works no matter which URL he navigates to (because the host page is loaded every time the user refreshes his browser). 
You can store the Userinfo in a global singleton and access it from your presenters to check it. 

2.) The JSessionId is only for protecting agains XSRF attacks (see here: http://code.google.com/p/gwt-platform/wiki/GettingStartedDispatch#Protecting_against_XSRF_attacks). It's independent of your application/user session management. 
You don't need to manually transmit anything from the GWT client when you use server side sessions, because that is done for you. You only have to check on the backend if the user session is still valid. 

3.) It's an anti-pattern for restful services to deploy server side session. However if you don't care too much about violating this principle you can still use server side sessions like in traditional web applications. 
Usually with restful services you have to transmit a secure token or the user credentials in every single backend call. You can also use OAuth. 

Williame

unread,
Jun 21, 2012, 10:54:42 AM6/21/12
to google-we...@googlegroups.com
For what it's worth I do a variation on #2.

When a user authenticates the first time in the server side session I add a couple of attributes that are never visible client side.  On any subsequent request to the server within my servlets I check to see if the session is null or not, then also are these special session attributes set.  if not set I consider it an invalid, unauthorized request and kick them out of the app, back to the login screen.

To keep the session alive a client side timer is used to send a keep alive to the server every 45 seconds.  This provides me with both the ability to keep the session timeouts low as well as notify the user within 45 seconds of network disconnect.

-W

Nikola Markovic

unread,
Jun 21, 2012, 3:10:45 PM6/21/12
to google-we...@googlegroups.com


On Thursday, June 21, 2012 4:54:42 PM UTC+2, Williame wrote:
When a user authenticates the first time in the server side session I add a couple of attributes that are never visible client side.  On any subsequent request to the server within my servlets I check to see if the session is null or not, then also are these special session attributes set.  if not set I consider it an invalid, unauthorized request and kick them out of the app, back to the login screen.

What if the user logs in and shuts down the browser and turns it back on ? Even though you logged in just a minute ago, you will be logged out, if I understood your approach correctly.
 

William Eubank

unread,
Jun 21, 2012, 4:20:56 PM6/21/12
to google-we...@googlegroups.com
Correct.  I lean to the pessimistic side for most of my apps.  I did not implement a "remember me" feature.

If I was developing gadgets/etc. I would not be so pessimistic.  Most of my apps are authenticating via ldap so users must already belong to our community and viewing/editing employee or student information.

-W

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/WLpGllHAsyUJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.



--
William Eubank 
Sr Software Development Lead
VBRH, M-1F
i.t. solutions
256-824-5375
william...@uah.edu

***No trees were harmed in sending this message but a few electrons were mildly inconvenienced.***



Reply all
Reply to author
Forward
0 new messages