Details
-
Type:
Task
-
Status: Done
-
Priority:
(None)
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: Client API: Authentication
-
Sprint:MEN Sprint 122, MEN Sprint 123
-
Story Points:13
-
Epic Link:
-
Backlog:yes
-
Days in progress:12
Description
Acceptance criteria:
- Move the authentication completely into its own Go routine, which the regular client calls using channels.
- No direct function calls to obtain JWT token shall be made, only via channels.
- At least two calls must be offered on the channels:
- GetJwtToken, must never contact server, only returned cached copy
- FetchJwtToken, Authenticate to the server to get new token (this should be called according to our existing polling rules).
- This call must be asynchronous, IOW it either starts or schedules the authentication, if needed, but does not wait for it to complete.
- It is allowed to just verify that the existing token works, without getting a new one.
- In addition, there must be a channel in the other direction which publishes when a token has become available. This must be published at least once after FetchJwtToken has been called and a token has become available (the client is likely waiting for it at this point).
- Feature branch: feature-client_auth_api
The motivation behind this change is to separate the deployment state machinery from the authentication, so that it cannot cause authentication to hang. At the moment it will still be in the same binary, but conceptually, the client will be a user of its own authentication API (see MEN-4009).
Also we could quite easily split out the authentication into its own binary, which we may do later.
If this seems like a weird implementation task, it may help to read MEN-4009, MEN-4016 and MEN-4017 to understand why we need this.
Attachments
Release management
Issue Links
- blocks
-
MEN-4009 Implement DBus API: GetJwtToken
-
- Done
-