| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inclusion of a sha256 digest of the full username to the logical session
id (in addition to the current guid) is necessary to fully disambiguate
logical sessions in degraded clusters (when the authoritative record for
a session is unreachable).
Semantics for the uid are as follows:
session creation via startSession()
* Sessions can only be created with one, and only one, user authenticated
* The composite key is created from a guid created on the spot, as well
as the digest of the currently auth'd username
* Only the session guid is returned to the user
* This prevents outside users from attempting to send back a value
we'd have to check. It's preferable to decorate the guid with the
user digest per command, rather than having to check a value the user
might send.
session use for a command
* Sessions are passed via the lsid top level field in any command
* Sessions are only meaningful for commands which requireAuth. For
sessions which don't require auth, we strip session information from the
command at parse time
* Session ids are passed as an object, which can optionally include the
username digest
* It is illegal to pass the username digest unless the currently
auth'd user has the impersonate privilege (the __system user does).
This enables sessions on shard servers via mongos
|
