API Authentification » History » Revision 2
Revision 1 (Kurt Gerber, 18 Dec 2019 10:03) → Revision 2/7 (Kurt Gerber, 18 Dec 2019 10:55)
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: ** o One to one relationship to the Registered UserID ** o 3 fields --> 'UserID', 'APPToken' & 'time_stamp' * • When an API request to create a case, upload images or edit cases is received ** o Authenticate with the API Token to ensure user has access to API ** o Check if the Authenticated User has an 'unexpired' APP Token *** ▪ A time limit is used to designate stale/fresh APP Tokens ** o User has no APP Token: *** ▪ APP Token is Generated *** ▪ Response is sent and the APP Token is included *** ▪ This is the initial handshake *** ▪ Time stamp is updated ** o User has an Unexpired APP Token: *** ▪ Request is accepted *** ▪ Time stamp is extended *** ▪ Response is served ** o 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 ** o 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