wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Rename nonce to txn_id. Reorganize for clarity.

Browse source 
Signed-Off-By: Isaiah Inuwa <isaiah.inuwa@gmail.com>
This commit is contained in:
Isaiah Inuwa 2019-11-29 10:16:23 -06:00
parent f37aa30c43
commit ad383351c2
1 changed files with 8 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

15
specification/client_server_api.rst
View file

@ -740,22 +740,23 @@ To use this authentication type, clients should submit an auth dict as follows:
"session": "<session ID>" "session": "<session ID>"
} }
The ``nonce`` should be a random string generated by the client for the
request. The same ``nonce`` should be used if retrying the request.
A client may receive a login ``token`` via some external service, such as email A client may receive a login ``token`` via some external service, such as email
or SMS. Note that a login token is separate from an access token, the latter or SMS. Note that a login token is separate from an access token, the latter
providing general authentication to various API endpoints. providing general authentication to various API endpoints.
The ``txn_id`` may be used by the server to disallow other devices from using Additionally, the server must encode the user id in the ``token``; there is
the token, thus providing "single use" tokens while still allowing the device therefore no need for the client to submit a separate username.
to retry the request. This would be done by tying the token to the ``txn_id``
The ``txn_id`` should be a random string generated by the client for the
request. The same ``txn_id`` should be used if retrying the request. The
``txn_id`` may be used by the server to disallow other devices from using the
token, thus providing "single use" tokens while still allowing the device to
retry the request. This would be done by tying the token to the ``txn_id``
server side, as well as potentially invalidating the token completely once the server side, as well as potentially invalidating the token completely once the
device has successfully logged in (e.g. when we receive a request from the device has successfully logged in (e.g. when we receive a request from the
newly provisioned access_token). newly provisioned access_token).
The server must encode the user id in the ``token``. There is therefore no need
for the client to submit a separate username.
OAuth2-based OAuth2-based
<<<<<<<<<<<< <<<<<<<<<<<<