WOCAT » QCAT

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.

*Caveat: This is very non-standard and maybe insecure*

* Use the existing API Token for Primary authentication in all cases

* Create a Secondary authentication table, as follows:

** One to one relationship to the Registered UserID

** 3 fields --> 'UserID', '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

** Authenticate with the API Token to ensure user has access to API

**  Check if the Authenticated User has an 'unexpired' APP Token

***  A time limit is used to designate stale/fresh APP Tokens

**  User has no APP Token:

*** APP Token is Generated (*...after successfull authentification, I guess*) 

*** Response is sent and the APP Token is included

*** This is the initial handshake

***  Time stamp is updated

**  User has an Unexpired APP Token:

*** Request is accepted

*** Time stamp is extended

*** Response is served

**  User has an Expired APP Token:

*** User is re-authenticated with the API Token

***  APP Token is refreshed

***  Response is sent and the new APP Token is included

*** Time stamp is updated

** User has Incorrect APP Token:

***  Invalid Response is sent

* Issues and possible solutions

** Conflicts when more than one user is trying to edit a case 

*** Use a Locking mechanism while user is Editing a case

**** This will prevent users from ending up with a conflict

**** Lock will be released after the APP Token expires

*** Conflict resolution:

**** Comparing the last updated time to the APP time stamp and determining if newer edits can be merged without conflict

*** Edited cases will be rejected if they are submitted after the APP Token has expired