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

    Sessions and contexts

    yagerhard

      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

        • 1. Re: Sessions and contexts
          csa

          Hi Mark,

           

          I have had really good success with this kind of stateless severs and token based authentication in the past. So, I'd definitely encourage you to try that. After an initial login request (e.g. an RPC call), you could store the token on the client. You can then use client-side interceptors in Errai to make sure the token is amended to all RPC/REST requests and updated when the response arrives.

           

          If you have ideas/suggestions as to how Errai's security module/picketlink integration could help here, please let us know, and we can discuss it either here or on the errai-dev mailing list.

           

          Cheers,

          Christian

          • 2. Re: Sessions and contexts
            yagerhard

            Hi Christian,

             

            I'll have a look into this. Could you send me a private email (mark at badorrek.com) and outline the various classes that I have to override etc in order to dynamically send addition parameters on the RPC request and response. Interceptors will probably get half the job done but I've a feeling that RequestBuilder (or whatever it is) will have to be extended. Any code snippits or thoughts are much appreciated.

             

            Cheers,

             

            MarkB

            • 3. Re: Sessions and contexts
              csa

              Hi Mark,

               

              Moving this discussion to a private channel doesn't help anybody discovering this forum entry in the future.

               

              The client-side interceptors for JAX-RS/RPC give you access to the RequestBuilder object over the provided call context. You can also set your own instance of RequestBuilder (context.setRequestBuilder).

               

              https://docs.jboss.org/author/display/ERRAI/Errai+JAX-RS#ErraiJAX-RS-ClientsideInterceptors

               

              Cheers,

              Christian

              • 4. Re: Sessions and contexts
                yagerhard

                OK - I'll post here and let you know how things work out.