API Authentification » History » Revision 4
Revision 3 (Kurt Gerber, 09 Jan 2020 15:33) → Revision 4/7 (Kurt Gerber, 09 Jan 2020 20:00)
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 *Caveat: This is very non-standard and authorisation maybe insecure* * Use the existing API Token for application authorisation Primary authentication in all cases * 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 one relationship to the Registered UserID (different mobile devices should be possible) *** ** 3 fields --> 'UserID', UserToken' 'APPToken' & 'time_stamp' --> (*Why not using the alredy exiting Django-based session?*) * When an API request to create a case, upload images or edit cases is received, follow the following use workflow: received # ** Authenticate with the API Token to ensure user has access to API # ** Check if the Authenticated User has an 'unexpired' UserToken APP Token ## *** A time limit is used to designate stale/fresh User APP Tokens * *Use case 1: ** User has no APP Token:* Token: # User has to authenticate to receive a UserToken *** APP Token is Generated (*...after successfull authentification, I guess*) # *** Response is sent and the UserToken APP Token is included. included *** This is the initial handshake # *** Time stamp is updated * *Use case 2: ** User has an Unexpired UserToken:* APP Token: # *** Request is accepted # *** Time stamp is extended # *** Response is served * *Use case 3: ** User has an Expired UserToken:* APP Token: # *** User is re-authenticated with the API Token # UserToken *** APP Token is refreshed # *** Response is sent and the new UserToken APP Token is included # *** Time stamp is updated * *Use case 4: ** User has Incorrect UserToken:* APP Token: # *** 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?*) Issues and possible solutions * This locking mechanism doesn't work with an offline application, because: ** The server only knows Conflicts when he sends or receives data, but it can't tell, if sent data more than one user is used for editing or view only. trying to edit a case ** *** Use a Locking as long as the application mechanism while user is offline won't work, as that can take days. * *Possible solutions:* * The server receives Editing a case data (JSON) as POST on respective API endpoint (for **** This will prevent users from ending up with a certain configuration/identifier): # Checking, if conflict **** Lock will be released after the latest version of the case is either _'active'_ or _'draft'_ APP Token expires # When latest version is _'draft'_, compares *** Conflict resolution: **** Comparing the last update timestamp updated time 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'_ APP time stamp and not _'active'_:* determining if newer edits can be merged without conflict # Data upload is *** Edited cases will be 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 they are submitted after 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.' APP Token has expired