API Authentification » History » Revision 6
Revision 5 (Kurt Gerber, 09 Jan 2020 20:00) → Revision 6/7 (Kurt Gerber, 09 Jan 2020 20:03)
h1. API Authentification
Proposed Solution
The following is a proposed authentication mechanism for handling mobile app requests. This is to facilitate other API endpoints allowing users to create cases, upload images and edit cases.
h2. User authentification and authorisation
* Use the existing API Token for application authorisation
* Use a second token for the user authentification. This can be solved bei either one of the following options:
** A: Using the existing django-based session ID, same as the web gui.
** B: Create a Secondary authentication table, as follows:
*** One to many relationship to the Registered UserID (different mobile devices should be possible)
*** 3 fields --> 'UserID', UserToken' & 'time_stamp'
* When an API request to create a case, upload images or edit cases is received, follow the following use workflow:
# Authenticate with the API Token to ensure user has access to API
# Check if the Authenticated User has an 'unexpired' UserToken
## A time limit is used to designate stale/fresh User Tokens
* *Use case 1: User has no APP Token:*
# User has to authenticate to receive a UserToken
# Response is sent and the UserToken is included. This is the initial handshake
# Time stamp is updated
* *Use case 2: User has an Unexpired UserToken:*
# Request is accepted
# Time stamp is extended
# Response is served
* *Use case 3: User has an Expired UserToken:*
# User is re-authenticated with the API Token
# UserToken is refreshed
# Response is sent and the new UserToken is included
# Time stamp is updated
* *Use case 4: User has Incorrect UserToken:*
# Invalid Response is sent
h2. Case locking mechanism
*Problem:*
* The web application contains a locking mechanism: A draft version is locked as long as a case open in an editor/form. (* Timeout?*)
* This locking mechanism doesn't work with an offline application, because:
** The server only knows when he sends or receives data, but it can't tell, if sent data is used for editing or view only.
** Locking as long as the application is offline won't work, as that can take days.
* *Possible solutions:*
* The server receives case data (JSON) as POST on respective API endpoint (for a certain configuration/identifier):
# Checking, if the latest version of the case is either _'active'_ or _'draft'_
# When latest version is _'draft'_, compares the last update timestamp to the timestamp of the UserToken
* *Use case 1: The latest version is _'active'_: *
# Creates a new draft version with the sent JSON
* *Use case 2: The latest version is not _'draft'_ and not _'active'_:*
# Data upload is rejected with: 'Case under review. Can't be updated'
* *Use case 3: The latest version is _'draft'_:*
# Checks if timestamp of last update on server is newer than the UserToken timestamp
* *Use case 4: UserToken timestamp is newer than update timestamp on server:*
# Merge sent JSON to draft version.
* *User case 5: Update timestamp on server is newer than UserToken timestamp:*
# Case was updated over another device / or over website
# Data upload is rejected with: 'Newer version exists.'