Re: Reusing User ID and Password with Zend i5_Program_Call

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

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