4 Replies Latest reply on Jul 25, 2013 8:53 PM by Mark Badorrek

    Sessions and contexts

    Mark Badorrek Newbie

      Dear all,

      I've just been looking through the PicketLink integration and will be giving it a try shortly. However, I do have a general question regarding contexts and sessions with Errai.

      I've in the middle of a project that has unfortunately put a little too much stuff in the SessionScope. As this is a JSF project (I quite like JSF) the sessions can become bloated as JSF will happily save a lot of viewstate information. So I've been thinking about what can be done to keep a server-side session as small as possible. What I considered was this:

       

      After after login, the server creates a small "context" object consisting of userId, LastInteractionDateTime etc. This is then encrypted and turned into a small array of bytes that is sent back to the browser. The browser obviously can't inspect it, but the byte[] has to be passsed with each request to the server. The server then decrypts it and confirms that all is OK, updates the LastInteractionDateTime to <now>, then sends that result back to the client along with whatever the regular payload of the response is. The client keeps the updated token for the next call to the server.

      The client and server should handle this little interaction with interceptors/whatever so that the application programmer is not burdened with the plumbing.

      If there is no session bytes array, or it won't decrypt, the server throws a "NotAuthenticatedException" back to the browser. If it does decrypt but the LastInteractionDateTime is too old, the server throws a "ReauthenticationRequiredException" back to the browser. Hooks to be provided for the client-side application programmer to deal with these.

       

      Advantages

      ----------------

      • "Stateless sessions" on the server. The client keeps the token and the sever can trust the token as the server alone can encrypt/decrypt it.
      • Adding servers to a farm is easy as there is no server-side session replication.
      • No memory usage for sessions on the server (the point of this exercise).

       

      Disadvantages

      --------------------

      • Some extra wire traffic
      • Some extra CPU cycles on the server.

       

       

      I'm not raising a jira around this - I'd just like others to see if there's anything wrong with this. Could this be done is some way with Errai/GWT's cookie management?

       

      Thanks,

       

      MarkB