GWT-Platform login + session management

I am new to gwt and I am creating a login page using gwt and I need help with session managment.

All answers already given here, explains how to manage sessions on server side, I need to use session on client side (browser's session) exactly like with JSP files: session.setAttribute("UserName", username);

Can any one provide a clear full example of how to implement this (Remember I am new to gwt). I looked at this tutorial: http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ And this doesn't help me because it doesn't explain how to use the browser's session.

Thank you.

回答1:

"I need to use session on client side (browser's session) exactly like with JSP files: session.setAttribute("UserName", username);"

I wish to correct your misconception. The following is not browser side code and not browser side session. It is server side code, managing server-side session info.

session.setAttribute("UserName", username);

You would transmit this server-side session info to the client in your JSP, for example:

<script>
var username = "<%=username%>";
</script>

Or,

<script>
var username = '<%=session.getAttribute("UserName")%>';
</script>

As an experienced JSP programmer, you would realise the decoupling between the HTML/Javascript (generated by the JSP) and the JSP itself. And for the limitations you had faced with JSP is the reason why you are turning to GWT.

The similarities between JSP generated client and GWT generated client

Occasionally (maybe frequently) programmers mistake server-side code as client-side code, vice versa. Just as you did.
Both generate javascript and HTML elements that is sent to the client to be executed.
Whatever you cannot do with javascript generated by JSP, similarly cannot be done by the GWT client-side Java source.
Whatever needs to be done by JSP generated client code, also needs to be done by GWT client code.
You can embed session information in the HTTP header, POST or GET parameters.
You need the client to maintain session info, mostly in the form of cookies.
Under certain circumstances, the jsessionid cookie is not set by server's response.
Your servlet or its container could generate the http set-cookie header for JSESSIONID.
The servlet can control when the cookie header is created - due to request.getSession().

The difference between JSP generated client and GWT generated client

JSP generated client is refreshed per request/response. As such, you can transmit changes and data between client and server for every request/response.
GWT generated client is persistent to the client and not refreshed. It is for this reason that you are turning to GWT.
This refresh difference is very crucial in understanding the difference in coding for GWT than for JSP.
All the Java code in JSP is server-side code. In JSPs, there are no client-side code written in Java. Even the Java code used for generating the HTML/javascript is server-side code.
All client-side Java code is translated/compiled into Javascript. So the GWT Java code is actually "compiler-side" code.

Means of communication between client-server in GWT

Don't forget to use the Dictionary class client side code to transmit your static settings to GWT app thro Javascript objects defined in the hosting file. You can set javascript objects as vars and they will be readable by the Dictionary class after the gwt module is loaded.
Don't forget that you can use JSP to generate the GWT hosting file - so that you can create different behaviours afforded by different Dictionary readings that you can individualise for each invocation of your app.
However, you should not place the session id or authentication info on the hosting file. Because even though dynamically generated by JSP, it is actually static on the persistent GWT client.
You can use Window.Location.reload() to needlessly refresh you GWT client, just in case you still love the refresh effects of JSP.
GWT-RPC
RequestBuilder
RequestFactory
REST and REST-RPC
Script include (for crossing SLD-SOP boundaries)

All client-server communication requires the GWT client to provide a callback, due to the asynchronicity of the technology.

Take a look at http://google-web-toolkit.googlecode.com/svn/javadoc/2.4/com/google/gwt/http/client/RequestBuilder.html (Or view it at your personal copy of the GWT javadoc).

... where you will be able to define set and get headers. Your server-side has to concur with the client what header name is used.

You do not need to depend on the conventional JEE session to "maintain session". You can contrive your own token framework. Or use an existing one, like OAuth or OpenId.

Under various conditions, you will not get session cookie set in the server's response.

Under certain circumstances, you may need to abandon the use of conventional JEE sessions altogether when writing a GWT app.

You should consider using REST or REST-RPC as I am attempting to document it (at a snail's pace) in: http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.

REST does not require you to maintain a session cookie. In my opinion, GWT works best with REST-RPC.

You could browse over previous posts there, where there are explanation on other forms of client-server comms with GWT.

回答2:

If you mean controlling instance of HttpSession on client-side, simply you cannot control the session on client-side since it lives on server-side. For controlling the session you have to call to the server-side with asynchronous callbacks or with another technique. Read this tutorial: Communicating with a Server in GWT On server side implementation you can set any attribute to session

HttpSession session = this.getThreadLocalRequest().getSession();
session.setAttribute("UserName", userName);

Or if you mean Client side web sessions, you can control them with Cookies.

回答3:

There is no such thing as Browser session. Here is what you can do:

Implement a GWT RPC which pings the server, retrieves the session timeout from server.
Start a timer on client side which runs for the duration of the timeout.
Reset the timer every time a service call happens.