Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson

Already subscribed? Sign In

Autoplay

    Send JWT Encrypted User Role Data from Client Local Storage to Express Server

    Mark BartonMark Barton

    This lesson will take the JWT sent from Express and store it in the browser local storage. It will then resend the JWT back to the Express server when a HTTP call is made for additional IBM Domino Data.

    This stateless method allows the server to trust what user roles the logged in user has to restrict what Express routes the user can call. For instance you might want to restrict all Admin routes to only users which have the Admin role in the Domino ACL.

    expressExpress
    jwtJWT
    nodeNode.js
    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Transcript

    Transcript

    Man: 00:00 Diving back into our index page, we want to enhance our get user roles function, and we're going to store the results that come back, which is our JWT file. I am going to store that in our local storage as well. Let's do that now.

    00:14 We'll get hold of the token value from the results, and what we need to do is include the word bearer. We're going to set our authorization header, which was going to go back to our node server. But to be a valid authorization header, it needs to have the word bearer in front of it.

    00:30 We're using the ES6 templating language, where you will store the result.data, which is our JWT token along with the string bearer.

    00:39 Next, we'll store the JWT token inside our local storage. Same as how we did with the node DOM auth session ID. We'll call this one node DOM USER INFO. If you're using the single page application, it'll be useful to set a default so that every call you make to the node server, automatically has your authorization header set, and at the same time the node DOM auth session ID as well.

    01:05 The Ajax's library has the ability to set default. Remember, this only really is valid if you've got a single page application, because, as soon as you change the browser page, you're going to end up having to set this again.

    01:19 Just to demonstrate it though, I will set it here. Ajax's default headers.common, and we will set the authorization one, and we'll set to auth token, at the same time we might as well set the node DOM auth session ID as well.

    01:37 I'll just copy that one. To demonstrate this working, what we'll do is, we're going to change our get Domino data method. This time, we will remove the local storage to get our node DOM auth session ID. Remember, we've set a default, we'll get rid of that. Leave everything else the same, and have a look at what it looks like in the browser. I have started my server, reopened my page, refreshed it, and I click the get user roles.

    02:04 We get back our JWT token from a server, and I check the local storage, we can see that it's set it in the node DOM user info, and there's the word bearer in front of the JWT token. If I now get the get Domino data, remember we're using the Ajax as the default here.

    02:22 If I look at the network tab, and look at the Domino data call, we can see that the authorization header has been set with the bearer, and the JWT token. The node DOM auth session ID has also been set. But, if I refresh my page, and try that again, get Domino data, you can see that we get a 401 because the defaults have no longer been set because we refreshed the page.

    02:46 In this instance, we would use the local storage to get hold of the information we need. Now, we just need to update the node server to manage the authorization token, and make sure that we can decode our roles.

    Discuss

    Discuss