Re: Reusing User ID and Password with Zend i5_Program_Call

Mike Cunningham wrote:

We are not using PHP but the same concept would work in PHP. We do the same as Scott. All DB connections from our web apps use the same userid/password for all calls. When the user first connects they have to signon. We call and RPG app to validate the credentials (we actually do a two step process, check Active Directory using LDAP and if that fails check local i5 directory). If the authentication is valid we create a session id, write it to DB2 table along with the userid (along with some other info) and set a session cookie with the session id. On all subsequent requests, if the cookie exists, we check the sessions id in the database and if it matches the app will respond, if not it redirects them to a logon screen. All of that code is also in a callable app that either returns the users credentials to the app or does the redirect

Two issues exist when calling the i from a web app: authorization and environment. In the i, both are handled at the job level, using the user profile for the former and the library list for the latter. Unless you have a separate job for each user session (the default behavior for green screen applications), you have to either emulate or ignore this behavior.

For user profile, you can swap profiles on every request using the profile handle APIs. If you ignore it, then you run into a number of problems that Nathan has listed, ranging from authorization to logging to ownership of created objects such as reports.

For library list, you can obviously change the library list on every request. It's a little on the expensive side, but I haven't run any benchmarks in a while. If you only have a single environment, you may also be able to ignore it, but I find that situation to be rare; I've usually got at least one other environment for testing.

The big divider is authenticated vs. anonymous sessions. Typically a web application will start in an anonymous session and then switch to an authenticated session when the user logs in (Google vs MyGoogle kind of thing). So for the most robust application you need a framework that supports both an anonymous business logic connection for the anonymous requests and some sort of authenticated connection.

The only other thing to remember is that the environment question applies to both authenticated and anonymous sessions, so environment needs to be addressed separately from authentication.

Joe