Authorea

Alec Aivazis edited How_do_we_store_the__.html over 8 years ago

Commit id: 05444758c9f9535c67313777c3f4f950241efad0

deletions | additions

How do we store the authentication data that we have retrieved?

Closures to the rescue! Create a function that is available globally in the success handler of the xhr request which will scope wrap the value of the data returned by the server in the closure. a read-only manner. The global scope of the closure makes the unencrypted authentication data readable outside that request and "safely" in memory in the sense that a malicious user can not modify it.

- It's by anyone who requires it.
  - - It's good to note that this request must be accompanied by valid credentials, so even that is secure.
  - If you wanted to add it to some kind of store that was accessible to the developer console (like redux) then we could not prevent them from easily modifying the data. However, hope is not lost. We can let them modify the data so long as we have some way of invalidating it afterwards.
  - In that case, we need some way of comparing it to a known valid state corresponding to the logged in user which we create when the user logs in and verifying that it is the same
    - That known reference would also be wrapped in a closure to prevent the malicious user from setting globally availible data and then changing the value of the comparison variable to match the new data.
  - In most cases, to achieve persistence, an additional request is required when the user logs in which decrypts the JWT. The server would respond with the authentication information which is in turn stored locally. This data is protected by the above algorithm since changing the value of the data used to authenticate invalidates it when comparing to the source of truth.
  - Authenticating the current user for the role admin then looks something like return isEqual(currentAuthInfo, sourceOfTruth) && intersection(auth.roles, targetRoles)).length > 0