java - Does a GWT app benefit from session clustering? -

a lot of java paases (such cloudbees session stores) offer session clustering/storage such doesn't matter server node user gets routed on particular request, server nodes share same stored session data, , serve can server client request.

i'm wondering how applies client-side mvc, single page app gwt app.

with gwt, of app executing client-side javascript. usually, time client hits server (via gwt-rpc or requestfactory) when client needs data, in case makes special call - under hood - gwtservlet.

my understanding of shared session storing applies httpservlet , back-and-forth dialogue between client (request) , server (response). doesn't seem apply in gwt-land.

so ask: gwt app benefit above-referenced application session store? why or why not? if so, concrete examples enormously appreciated! in advance!

example:

i have app allows client-side users perform actions:

public class backofficeservlet extends httpservlet {     @override     public void dopost(httpservletrequest request, httpservletresponse response) {         user u = getuserfromrequest(request);         action = getactionfromrequest(request);          // if user allowed action, it.         if(useractionauthenticator.actionisallowed(u, a))             a.execute(u, request);     } } 

how/where httpsession used add security or functionality not present in code sample above?

using session clustering makes sense if use session stock data. ask you: need save in server side session? if response no, there no need use session clustering too. gwt statefull client side. of time can eliminate need server side session saving session data in browser directly. give example wan't (and in case session clustering useful):

imagine app backoffice. each user must logged in , can have different roles. list roles present on client side (to able show/hide ui controls) , on server side (linked session, make same checks twice on server side). can't trust roles client side because may modified end user directly in browser (even if it's very complex task in case of minified js). here have 2 options: 1) use server side session 2) emulate server side session (send custom session token in each rpc call , reload each time user roles). prefer first option give me ability reuse existing security libraries spring security (save me lot of time / bugs). may choose second option depending on needs (your project has enough resources implement , test own implementations server side session emulation , security aspects, making stateless server side).

to summarize:

1. you have sensitive session data -> store them in server session -> need session clustering
2. your session data not sensitive / not have them @ -> stock them in browser / nothing stock -> not need session , session clustering
3. you have sensitive session data -> store them somwhere on server side , reload them each request using custom session emulation technique -> not need session clustering (but need more time option 1).

edit. in code sample above can have following potential problem:

1. user logged in user1 (which have role_user permission).
2. he generate somehow request user2 inside (which have role_admin permission) , action can executed if have role_admin permission.
3. this action executed, if user1 not have corresponding permission.

the cause of problem user object comes untrusted source (request) , can modified end user. instead of storing him on client side can store him on server side example using server side session:

public class backofficeservlet extends httpservlet {     @override     public void dopost(httpservletrequest request, httpservletresponse response) {         user u = getuserfromsession(request.getsession(false));         action = getactionfromrequest(request);          if(useractionauthenticator.actionisallowed(u, a))             a.execute(u, request);     } } 

now can trust user object, because end user cann't change session objects.