In the previous article we displayed, in a browser window, all the employees in our company. Probably not something you would wish to make public to the whole company!
So, how can we restrict access to the employee web page?
Our flow will be:
Show the login page.
If a valid IBM i User Profile and password is input, allow access to the employee page, via a button link.
Clicking the Employees button will render the employee page, which we developed in the last article, which can be found here if you missed it!
If a user tries to access the employee page directly using the employee URL, they will get a not authorised message.
To validate our IBM i user ID and password, we are going to call an IBM API, that will tell us if the user is valid, we can then store the results so we can use them elsewhere within our application.
IBM API Call
IBM has provided an API, called QSYGETPH, which allows us to verify a user ID and password. IBMs link to this API can be found here.
This API has been available since V2R1 of OS/400.
Storing the Results
When we have the results of our API call, we need to store the results somewhere. I am going to capture this information in a cookie. It will then be available to all pages on our site, where we can check if a user is authorised to that page or not.
Before we move onto any coding, we need to include a couple of external modules in our project. These are:
In a PASE shell, use NPM (Node Package Manager) to install these two modules.
Before we go any further let me have a quick couple of words about these packages.
The itoolkit module allows us the communication and add functionality that we have typically on a 5250 screen. Call programs, access database, execute commands, etc., etc. A very useful module.
For further information and documentation, see their GitHub repository here.
The client-sessions module allows us to store information in a cookie, that is then accessible throughout our application. For the PHP programmers out there, this is very similar to the $_SESSION global variable.
For further information or documentation, see their GitHub repository here.
The first place we need to start is the sign-on page.
Let us code the screen layout first, the signon.pug file. This has to reside in the /views folder.
This signon.pug file is shown below with all the associated explanations.
For the sign-on, we need to create a new file in the /routes directory. I’ve called this signon.js
The first part of this file is only concerned with showing the input for the user ID and password fields.
The next step is to add the post function to our signon.js file.
This coding is shown in the figure below and the explanations.
If you have been following this series of Node Express articles, you will know this is the app.js file, found in the application root directory.
We have to amend this file to allow our signon.js be accessible.
Now our application, with its sign on additions, is ready to go.
Point your browser at the application, prompting for the sign-on.
If we have entered valid details, the employee link will be available.
Clicking on the link, displays our employees.
Wow – Working as intended 😊
I suppose we had better test the direct access too. Entering the /employee URL without signing in produces the following.
As with all my previous articles on this topic, these changes have now been published to my GitHub repository, which can be found at this link. Hopefully, this will provide you with a template to experiment with Node.js on IBM i.
Take a look and have a play!
Hopefully in this article I’ve shown how easy it is to call IBM API programs on our IBM i to allow security within our applications and how easy it is to use all the services that we have available to us.
We will further enhance our application in my next article.
If you have any questions, either on this article, or any other open source, use the comments below, or send me a message on twitter @AndyYouens
Andy Youens is an IBM i consultant/instructor at Milton Keynes, UK-based FormaServe Systems with over 40 years IBM midrange experience.
Kevin Vranken says
Are the pictures broken?