Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    RESTHandler creates session?

    SmartClient Version: v9.1p_2014-06-25/PowerEdition Deployment (built 2014-06-25)

    SmartClient Version: v9.1p_2014-08-24/PowerEdition Deployment (built 2014-08-24)

    Hello, I've noticed that the every REST request served by the RESTHandler in my webapp creates a new session.
    I thought that spring-security was the culprit (even if the setting for the RESTHandler URL is <security:intercept-url pattern="/isomorphic/RESTHandler*" filters="none"/>
    ) but setting create-session="never" on the <security:http> tag didn't change the situation.

    So my question is: does the RESTHandler itself creates a session?
    I think not, but actually I've extended the RESTHandler class to override the handleDSRequest method. In my implementation, I do:
    Code:
    ...
    rpcManager.setAuthenticated(Boolean.TRUE);
    rpcManager.setUserRoles("ROLE_USER");
    rpcManager.setUserId(userId);
    return super.handleDSRequest(dsRequest, rpcManager, context);
    Does those setXXX on rpcManager could force the session creation ?
    Last edited by claudiobosticco; 10 Sep 2014, 05:17.

    #2
    No, RESTHandler does not force session creation. Like the handling in IDACall, the session is accessed if authentication-related features are used, and the servlet engine and/or authentication system you have in place makes the decision as to whether there is a new session or not.

    Your results suggest that whatever is being used to track the session - a cookie, URL parameter or similar - is simply not being passed to the RESTHandler servlet.

    Comment


      #3
      Originally posted by Isomorphic View Post
      No, RESTHandler does not force session creation. Like the handling in IDACall, the session is accessed if authentication-related features are used, and the servlet engine and/or authentication system you have in place makes the decision as to whether there is a new session or not.
      ok
      Your results suggest that whatever is being used to track the session - a cookie, URL parameter or similar - is simply not being passed to the RESTHandler servlet.
      sorry, I'm not sure to understand and/or to have explained myself well: the problem is that the session *is* created, and I do not want this.

      Could those method calls:
      Code:
      rpcManager.setAuthenticated(Boolean.TRUE);
      rpcManager.setUserRoles("ROLE_USER");
      rpcManager.setUserId(userId);
      force session creation?

      Comment


        #4
        I'm still investigating, but I've verified that upon entering the handleDSRequest method, dsRequest.getHttpServletRequest().getSession(false) returns a session, so the rpcManager.setXXX calls aren't the culprit (and neither the RESTHandler.handleDSRequest method)
        Last edited by claudiobosticco; 10 Sep 2014, 05:54.

        Comment


          #5
          As you seem to have discovered, no, those calls would not create a session. But of course there are innumerable features in the system that by necessity will access the session in order to do their job (the $session Velocity variable to pick a random example), and of course your own DMI or other custom code could do so.

          Let us know if you isolate a test case where session creation is forced and it's not actually necessary.

          Comment


            #6
            Originally posted by Isomorphic View Post
            As you seem to have discovered, no, those calls would not create a session. But of course there are innumerable features in the system that by necessity will access the session in order to do their job (the $session Velocity variable to pick a random example), and of course your own DMI or other custom code could do so.
            thanks for reminding that
            Originally posted by Isomorphic View Post
            Let us know if you isolate a test case where session creation is forced and it's not actually necessary.
            ok, for now actually it doesn't seem to be the case, thank you very much.

            Comment

            Working...
            X