XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: C4A Portugal Workshop
    • Component/s: None
    • Labels:
      None

      Description

      Currently the sessions in kettle is based on express' sessions, including the dependence on session ids beings passed around in cookies. This is not what we need in the GPII, as this requires a cookie with a session ID to be passed along with any request sent to the flowmanager. This is problematic in that we dont have a single client using the flowmanager - instead, we have multiple independent clients (eg. the different user listeners, PMT, PCP, Snapshotter, logger, etc) who need to communicate with the flowmanager.

      An example illustrating the problem with the current session:
      a) user logs in with the PMT (PMT sends the request without a cookie)
      b) Cookie with session ID is passed back from Flowmanager to PMT, to be used for any subsequent request
      c) The user uses the USB user listener to log out - the USB does not know of any cookie or session ID, as it's stateless and stand-alone - so it does not send along a cookie)
      d) The system fails with a "no session found" error, as the flowmanager has no cookie to help find the current session.

      We believe that there at any one time will only be one active session on a locally installed system. Therefore we do not need to support multiple concurrent sessions, and can allow access to the session without presenting a cookie. Furthermore, we want to allow calls like http://localhost:8081/token - in which we dont necessarily know the token of the currently logged in user. Hence we cannot always rely on requiring the token to identify the session. We DO need to support (one) session/state in the flowmanager when running locally, to allow different clients (eg. PCP/PMT/user listeners/ "/token" requests, etc to query and affect a current logged in user.

      In the kettle testing framework, a cookiejar has been implemented, keeping track of cookies. Therefore this problem wasn't caught by the acceptance tests. The first step in solving this JIRA would be to remove (or disable) the cookiejar from the testing framework, seeing the tests fail, and then making them pass again.

      Justin Obara is currently looking into writing a script for (manually) testing the PMT/PCP, which should allow us to check that this issue is properly fixed.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                kasper Kasper Markus
                Reporter:
                kasper Kasper Markus
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: