You are currently on IBM Systems Media’s archival website. Click here to view our new website.


Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The finer points of OpenRPGUI, Part 1

Authenticating a user is common in the IBM i world. Users aren’t really allowed to do anything in regards to our programs unless they’ve first authenticated themselves via the 5250 sign-on screen. The Web changes that a bit because it’s so much more than just a means to enter data and instead includes and requires flavors of marketing and enticing the user to proceed. Our practices of requiring a user to first log in before continuing is oft a big no-no in the Web world. Imagine if required you to log in before you could search for a book or other product? That would significantly limit its reach into the marketplace. Instead it lets you fully go through the shopping cart process and only require you to sign in or sign up when you’re ready to finalize the transaction by paying for it.

Do We Need to Change?

Obviously you have sensitive information that you can’t allow end users to see, but the products you’re selling aren’t in that category and should be easily accessible to users. Obviously, external and internal users will have access to different things and be required to authenticate at different points. My reason for bringing this up is that we as IBM i developers get to ponder how the Web changes the landscape of application-to-user interaction and determine how we need to change our traditional approach to application authentication.

IBM is now charging per user profile in the past few releases of IBM i, so making use of IBM i user profiles should only be done only for internal users who might also be using the green screen for other applications. In this article, I’ll describe how to, from a Web application, authenticate against literal IBM i user profiles by making use of the QSYGETPH system API that’s prototyped in Figure 1.

Authenticating on the Web

To show you how to authenticate in a Web scenario, I put together a small application that allows the user to log in via an ExtJS form, shown in Figure 2. Only two fields are required—user and password—and then the user can either select the Login button or hit the enter key. Acting on key-stroke events is a new feature I’m introducing in this article. Figure 3 is a PDF and gives the full login.html and LOGIN.RPGLE source for this application to make it easy to gain the big picture of how the application is coded. In Figure 3, if you scroll down to the pnlLogin declaration and then down to the 'pwd' fields declaration, you’ll see the 'listeners' config option listening for the ENTER key. I could have put my communication-to-the-server code in the listeners config section but instead it’s best to emulate the clicking of the Login button as much as possible, and that means invoking the same btnHandler JavaScript function with the name of the button that would have been invoked if the user had actually clicked on the Login button.

If you’ve been following my other articles, you’ll notice a new config option of submitForms on the various buttons configs. The submitForms config option is something I created. It turns out that ExtJS lets you add any additional config options you might need to “extend” an existing config. This can be quite helpful and somewhat dangerous. It’s helpful because I can add metadata, but dangerous because I could mistype something, like inputtype vs. inputType, and get a totally different result because ExtJS might think I mean to add functionality. I created submitForms so each panel definition could declare which panels and forms should be submitted when a button on the current panel or form is clicked. This let me create totally generic code in the btnHandler JavaScript function and greatly reduced the amount of coding whenever I added a new button—yet another powerful benefit of JavaScript and ExtJS.

At this point the btnHandler JavaScript function communicates the request to the server. It should be noted that you should use HTTPS, or rather, HTTP + SSL, whenever you’re asking the user to send sensitive information over the wire. Our OpenRPGUI program, LOGIN.RPGLE in Figure 3, is then invoked followed by subprocedure btnLogin. It’s in here we see the QSYGETPH API being invoked. I use this API to 1) validate a user profile and password, and 2) obtain a handle for that profile back into our program so we could subsequently use it to, say, switch this job’s current user from Apache’s QTMHHTTP profile to the one that’s attempting login. I’ll address the second purpose in another article. In this case, we only want to know if we should allow the user to proceed to the next page. If the QUSEC data structure returns any number of bytes in the errBytesAvail subfield then we know there was an error and we should respond accordingly with a message. If the authentication was successful then we can hide the pnlLogin and show the pnlHome—both defined in login.html as shown in Figure 3. Take special note of the %xlate being used to convert the user profile to uppercase. It only took me about two hours to realize that the QSYGETPH was expecting uppercased user profiles—yes, I ate humble programmer pie for lunch that day.

The pnlHome definition isn’t anything special. I just needed a second screen for the user to navigate to should they authenticate successfully. On the pnlHome screen is a REFRESH button that will ask the IBM i server the current time. The more important button is LOGOUT, which first clears out the 'user' and 'pwd' fields and then hides pnlHome and shows pnlLogin. That’s it! You now know how to login and logout a user. In a future article, I share some approaches to ensuring a user has logged in and didn’t just deep-link themselves to a second level page or panel.

Final Notes

The other thing I wanted to note is at the very top of the login.html file where the ExtJS libraries are being referenced with the <style> and <script> tags. Notice how they’re fully qualified paths to the site vs. a relative URL. This effectively means I’m not using the ExtJS installed files on my server but am instead pulling them off of an SVN repository on Google’s domain. I just started trying this approach on my most recent OpenRPGUI projects and am not sure yet if it’s something I like or not. The benefit is that you aren’t using your bandwidth to download the ExtJS framework to each machine that accesses your site and also saves you from installing ExtJS. The downside is if Google’s site goes down, then your site will be rendered useless; Even Google isn’t perfect in their uptime.

On final note, Mihael Schmidt, the creator of the JSON service program used in OpenRPGUI, just contacted me and stated that a new version of his JSON code is available and has a number of changes. In particular, the issue with bracket characters being translated incorrectly with various CCSIDs has been addressed. You can read about the issue in this forum entry.

Aaron Bartell is Director of IBM i Innovation for Krengel Technology Inc. and an IBM Champion.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters