Authenticating on the Web
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 Amazon.com 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
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.
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 googlecode.com 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.