session handling in GWT

[bg]

I'm at a bit of a loss when it comes to session handling in GWT.
Coming from PHP, which took care of session handling for you, I never
had to put much thought into it. It was much more trivial when all the
code was on the backend and it was just spitting out content to the
client. I've done some initial research, and it appears that java
servlets has its own session handling, but how well does this work with
gwt? Since my applications only contact with the server is through
RPCs, I assume that the servlets built in session handling won't work,
since the browser will likely not parse header information from a
returned rpc call (if there is any??). I'm concluding at this point
that I'd have to implement my own session handling, which I'm not
really against, I enjoy this kind of stuff. Please let me know if I'm
wrong though.

In implementing my own session handling, I was thinking I would have a
service that would be used for generating a session id and passing
this information to the client. The client would store the session id
as a cookie, and would pass the session id back to the server during
any user-specific RPC's. The session ids would be stored in a db on
the backend with the corresponding user id.

Please share your opinions and thoughts regarding this.

I appreciate your help,

B

[Berzehk]

the built in session from java servlets works perfectly in GWT. Just
look for the getThreadLocalRequest() function.

[Bob]

We do not use http servlet sessions. There is another post in here
that explains a different way that we decided to implement. When the
user signs on, your server assigns the client a "token" that is sent to
the client and stored in a database on the server. Then each request
back to the server includes that token from the client that is verified
in the database before the request is fullfilled. On the server, we
store tokens in a database and use that identify the user and valid
requests. It may be reinventing the wheel a little, but it was not
difficult and has given us flexability with other items. I think this
is the way Google mail works. As I understand, servlet session rely on
the browser having cookies enabled, etc. Also this approach is not
very scalable since everything is store in memory (sessions and any
items you try to store in it from client request to client request).

Research the vairous approaches before you implement since you'll be
stuck with as you build your solution around it.

[charlie...@gmail.com]

I believe more to the point, though yes server side sessions are still
there, is that you do not need a session in the prototypical GWT
application. What I mean is that, with PHP (which I also used for
years) you might store the userID, or messages, or objects spanning
across multiple pages before you submit them and so on in the session.

With GWT, on the other hand, you simply make a client side data model
and include/keep those things on the client. For example a userID, you
have a UserWidget that accepts user/pass and then makes a server RPC
call that returns valid or not (or returns the specific "id" from a
database, or returns an entire "User" object - oversimplified example),
then you simply put that in a client side data model, bam, it's there
whenever/wherever you need it. (And if you have a form spanning
multiple pages that is no problem either, you update the same model
client side as you go.)

I also typically create a simple client side "Controller" that handles
events, and updates the model, and the view listens to the model and
updates when the model changes. So for example when the user logs in,
the User object changes, and the view, being a listener to the data,
updates and removes the login widget and replaces it with the
"UserWelcome" widget or something (now you are logged in, welcome user,
here is the menu to change your account profile, do stuff in the app,
etc). (Yes thats MVC, not trying to trivialize this, it is just a
different scope of MVC than server side developers are accustomed to -
so it is worth noting.)

Now this takes some getting used to for a more server side oriented
developer (which I myself am primarily - so at first it threw me for a
loop and I was asking the same questions) but once you start doing it
it makes perfect sense and solves a lot of problems, including the
"session" thing.

GWT, when done right, is really much like a three tier SWT or Swing
app, there is data ON THE CLIENT to keep track of stuff you might
typically put in a session, and then you persist, sync, validate data
with the server only when you really need to.

Another thing that can be tricky at first is that you are working with
a single page. I know this seems obvious, but again it can be strange
for stubborn old request/response type developers (myself). You do not
want multiple modules or multiple pages (as I have seen some posts in
the forum referring to, another story and discussion in and of itself,
but the bottom line is that if you are doing that you are fighting
against the grain, even in large or "enterprise" apps). Your single
page should swap in and out widgets or components as needed for the
state of the application, you do not login and then go to the "shopping
cart" module/page and such, rather once you login the parts of the app
needed for "logged in" state show up on the same page, the parts not
needed for that state disappear.

I know that last part was way off topic, but it confused me at first,
along with the data/session thing (especially with some of the forum
talk) so I threw it in there.

[bg]

The "token" idea if very similar to the self-implemented session
handling I proposed, which is likely the way I will handle it. I plan
on using cookies, only because I want the user to have the option of
staying logged in if they wish.

For security reasons, I would rather have the client hold as little
database specific information as possible. A logged in client doesn't
need to know its own user id, and if you trust a client to pass the
correct user id to the server during calls you will have some security
issues. Clearly, the server needs some way of identify the user on the
other end, which is what the session id will be for. The server will
generate a session id, pass it onto the client upon successful login,
which will be passed back to the server upon any subsequent calls. The
server will use the session id to reference the user id in the
database. In this case, its much harder for somone to hijack a
session, when, for example, its a random 64 character string, instead
of, in the case of a user id, a number that is predictably an
AUTO_INCREMENT field in the database.

This is slightly off topic but...
To be honest, the GWT way of doing things feel much more natural to me,
with all communication with the server done using RPC's. I was in the
process of writing an PHP framework to facilitate this kind of process
but quit as soon as I took a look at GWT. Java was different at first,
I had messed with it before years ago, and took a little getting used
to. Now however, I would be happy if I never had to touch php again in
my life. I would take the time to learn JSP before doing so. You
gotta keep in mind, I'm used to the half-assed OO implementation in PHP
5 and VB 6(that was a while ago) so learning java has been awsome.
Loosely typed languages seem lazy to me, and from my experience only
create more work for the programmer when you need to manually check
datatypes because you never know what may be flying around. Oh and GWT
introduced me to hands down, the best IDE i've ever used... eclipse.
Ok now, thats enough of my java/gwt love fest.

[MHu]

I'm lost reading these long message ...

The bottom line is that you will always get a session when
communicating using GWT RPC. The servelet engine that hosts your RPC
server impl will always maintain a session for your client. The session
cookie is sent back and forth between the browser and webserver which
you can check using any HTTP header monitor. GWT RPC is just wrapped in
HTTP req/resp, so your session handling will be exactly the as on your
PHP server - you don;t need to do a thing yourself. If you want to
tweak the session, play with web.xml.

[charlie...@gmail.com]

On the client versus the server holding the data . . . obviously when
you need to perform some function on the server side you have to
validate things, I was not merely suggesting the userid be passed by
the client every time without any validation (and a "token" is one way
to do the server side validation on the next call), but giving a very
rough example of why a session is not required nor desirable. And
actually you want as much data as is possible to handle on the client,
on the client, that is part of the point (then sync/update it when
required - and yes validate that data ON the server).

[Berzehk]

I am wondering, why do you need to use something different from the
built -in http sessions?
I mean, what's impossible to do with it ?

[charlie...@gmail.com]

This is true also. You can get at the existing session on the server
side through getThreadLocalRequest() - so you could use said session id
there as a "token" as well. The difference though, and need, is that
your calls to GWT service servlets will not be automatically associated
with the session (even though the container will still maintain a
session), you will need to do that yourself (by passing said "token" as
a parameter or such).