Store an IBM Domino Cookie sent from a Node.js Server in Browser Local Storage

Instructor: [00:00] To demonstrate getting restricted Domino data via our Node server, we're going to add a new button to our login form. This is on our index.html page. We're going to create a new function called Get Domino Data.

[00:15] This function will use the aoxis library to go off to our Node server, which in turn will make a request to Domino for some data. Our URL will be calling a route on our Node server, and we're going to call this one Domino Data.

[00:37] Don't forget to add an error handler. For now, we're just going to log out the results, the same with the error. Let's switch to our Node server and add in the new route. Back inside our server.js file, in the Node server, we'll add a new route for our Domino Data. It's a get route.

[01:01] Similar to previously, we're going to be calling our Domino database, which has an ACL with anonymous set to no access. Again, we want the complete response. We're using the request-promise library.

[01:18] Just like previously, we will deconstruct the headers and body from the response. The first thing we need to do is check for a Domino authentication failure custom header. Remember, we defined this on the custom login form, on the DOM cfg database.

[01:35] If there is a Domino authentication failure, we will return straight back to the browser with a status of 401, including the contents of the header. If not, we will return the contents from Domino straight back to the browser.

[01:54] Remember to handle any errors so we'll catch them here. If there are any errors, we will return them straight back to the browser. Let's test that using our web page. We've restarted our Node server and opened up our index page.

[02:13] If I click the Get Domino Data button now, and I look in the network console, I can see I actually got a 401 unauthorized. As we would expect since we're accessing a restricted database. Our response is, "Please identify yourself."

[02:30] On our login form, if we try and log in now, I click my login button. If it's successfully logged in, which is good, as you can see, with a 200. Importantly, we get back our cookie reference. Somehow, we need to pass that cookie reference through to our Get Domino Data call.

[02:51] Let's do that next. Opening up our index.html page again, we're going to enhance our login function. What we're going to do is we're going to record and store the response back from the Node server with the Domino cookie.

[03:06] We are going to use the browser's local storage property, which gives you access to a storage object. Local storage will survive a browser restart, and depending on how your sessions expires, the user may not need to have to log in again.

[03:21] Local storage takes a key, and natively, you can only store text in local storage. If you have a JSON object, you need to convert it to a string. In our case, we only need a cookie value. Therefore, we don't need to convert it.

[03:38] To test that, we fired up our browser again, opened the index page, and I'm this time going to log in. I've logged in successfully. Now I'm in Chrome. I'm Chrome tools, if you look under application, under storage, you'll find local storage. As you notice, local storage is dependent on your domain -- localhost in this case.

[04:00] Here, we have our value. We have the cookie value being stored in local storage. We can now use this value every time we want to make a call to our Node server. We've reopened up our index page, and we're going to enhance the Get Domino Data function.

[04:19] What we'll do is try and get hold of the Node DOM of sess ID, which is stored in local storage. The method we need is getItem, and we pass in the key. We should check to make sure that we have a value.

[04:35] If we do, we can then set a header on our options, which we then use in the aoxis library. This custom header we will pick up and use on our Node server. We'll now modify our server.js file to manage this custom header.

[04:54] Opening up our server.js file again, and we're modifying our custom route for Domino Data. What we need to do is deconstruct the headers, specifically looking for our custom header called Node DOM of sess ID.

[05:14] Now you have a choice. You could say that this URL is always going to be restricted and, therefore, if you don't have this custom header immediately returned back to the browser. I actually prefer if you just let Domino handle the authentication itself within our custom header down here.

[05:30] Therefore, within the options, we now need to set the cookie value that we have to set to Domino. Domino expects a cookie, and it has to be called DOM of sess ID. We can use some ES6 templating here to insert the value.

[05:47] Now we can fire up the server and test it again. I've restarted my server, refreshed my page. Notice my previous cookie value is still available in the local storage, even though I've restarted my browser.

[06:01] In Chrome, if you want to delete it, you just highlight it and press delete on the keyboard and it's gone. I'm going to re-log in to get a new cookie. The value's been set. If you look at the network tab and click my Get Domino Data, hopefully, this time, I get a 200, and my response is Domino Data coming back successfully.

[06:21] That's working fine. Going forward, now I can use that local storage cookie to talk to my Node server to Get Domino Data as an authenticated user.