this is for holding javascript data
Alec Aivazis edited untitled.html
over 8 years ago
Commit id: 73e6cd7bfcdeeaab7621aee364a724e945a04a99
deletions | additions
diff --git a/untitled.html b/untitled.html
index e8e9cf3..dc92551 100644
--- a/untitled.html
+++ b/untitled.html
...
In a single page app, all of the decisions about what view/subview to render occurs on the client and does not require a trip back to the server.
This means that the client has to be able to authenticate the currently logged in user and access its data without going back to the server which means it has to be stored locally.
JWTs are good because they allow for the client to be responsible for keeping track of the permissions of the currently logged in user.
However JWTs require a secret key to be decrypted which means it can't happen on the frontend with the same key that the server uses, say for its
csrf protection
Because of this it's clear that we need to have unencrypted way of viewing the local authentication data for use by the application logic
Special care needs to be made to prevent someone interacting with the developers console to be able to change the local authentication data in order to gain access to restricted parts of the code by elevating their permissions
Closures shouldn't
Since we have to at least talk to the server once in order to login in and authenticate the credentials, we can save a copy of the authentication information in a way that prevents it from being easily changed by the console.
Closures to the rescue!
Create an anonymous a function that is imported wherever the authentication information is used and returns but gets its value in the success handler of the xhr request which will scope the value given of the data returned by the server on login.
If in the function. This makes the unencrypted authentication data inaccessible outside that request and "safely" in memory.
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
In most cases, to achieve persistence, an additional request is required when the user logs in which decrypts the JWT and sets the local data JWT. The server would respond with theuser authentication information. information which is in turn stored locally. This data is protected by the above algorithm since there are checks for changes and can be freely changing the value of the data used to authenticate against for subsequent requests so long as there is a step that verifies invalidates it against when comparing to the known good copy.
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