Uploaded image for project: 'Mender'
  1. Mender
  2. MEN-4015

Isolate client authentication and move to separate Go routine




      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:
        1. GetJwtToken, must never contact server, only returned cached copy
        2. 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.


          Release management

            Issue Links



                tranchitella Fabio Tranchitella
                a10040 Kristian Amlie
                0 Vote for this issue
                1 Start watching this issue