Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-10552

Docs for SERVER-28334: Implement the startSession command

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.5.9
    • Affects Version/s: None
    • Component/s: None
    • Labels:

      Documentation Request Summary:

      https://docs.google.com/document/d/1ROSvJYvuV8aZL663bfs4pd0-bl2Pupq-EmrhcgJ9Flw/edit#heading=h.chi90z5clxyh

      startSession()

      { startSession : 1 }

      This command will cause the cluster to generate and return a new session record.

      If --auth is on, then exactly one user must be authenticated in order to run startSession. If this is not the case, then the command will fail with an error. Only users with adequate permissions may run startSession (see Authorization for Sessions). The user running startSession becomes the owner of the new session. In order to run future operations inside the session, on the same connection or on different connections, the session owner must be authenticated.

      If --auth is not enabled, then startSession will not require a user to be authenticated in order to run. If no user is authenticated, then new sessions created via startSession will not have an owner, and may be used on any connection. If a user authenticates anyway and runs startSession, then she will own the newly created session. Because --auth is off, however, even sessions with owners may be used by any user on any connection.

      If at any point --auth is turned on in the cluster, sessions without owners may not be used. Attempts to use unowned sessions for further operations will receive an Unauthorized error. Users must authenticate, create new sessions, and then use those new, owned sessions instead. If the cluster is then restarted without --auth, the original sessions without owners may once again be used.

      This command may be run against any server in the cluster.

      Guarantees:
      New sessions will have an id that is unique within the cluster.
      Servers may cache information about the new session for future operations.
      The new session may subsequently be used with any server in the cluster.
      All new sessions will have a fixed sessionTimeout value.
      Subsequent use of a session implies liveness and extends its lifetime.

      Returns:

      { "id" : <BSONObj>, // a signed logical session id "timeoutMinutes" : <int> }

            Assignee:
            kay.kim@mongodb.com Kay Kim (Inactive)
            Reporter:
            emily.hall Emily Hall
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:
              6 years, 40 weeks, 1 day ago