The other method is to provide stored procedures for the portal team to use. You could have one to authenticate a user, one to get address >information, one to get financial information, etc. With stored procedures, your database is much more independent of the portal and when >Bob uses the portal, the stored procedure he (indirectly) calls can do a profile swap and operate under USRPRF(BOB).
There was/is an exit point program product out there that allows you to "define" your own server within its structures. It supplied/supplies an API to access the authorization rules you set up for your server. It allowed/allows use of all the functionality found for IBM's servers.
Just a thought but the stored procedure Buck mentions could call the API to audit, authorize, profile swap, etc.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Wednesday, June 12, 2013 1:36 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: WHO is connecting via QRWTSRVR jobs and editing data?
On 6/12/2013 3:50 PM, Eric Lehti wrote:
do a "profile swap on additional server requests"
Buck, is your technique the typical solution for authenticating web
users logging onto IBM i? I confess that I am not familiar with web
portal authentication or how to perform a profile swap. I imagine
this action would occur in the PHP code.
There are two broad possibilities for a PHP-based portal accessing DB2 for i data. Directly embedded SQL (SELECT x,y,z FROM table WHERE...) is one, and it is the ugliest. One can't make changes to the database without meshing with the portal developers. They need to know a lot about the layout of the database. And about the only lever you have to control the situation is the authority of the APACHE profile.
The other method is to provide stored procedures for the portal team to use. You could have one to authenticate a user, one to get address information, one to get financial information, etc. With stored procedures, your database is much more independent of the portal and when Bob uses the portal, the stored procedure he (indirectly) calls can do a profile swap and operate under USRPRF(BOB).
I will ask our PHP web administrator and also post your observation to
IBM tech support and ask them how I can implement your suggestion.
Our web users are, of course, authenticated by Windows when they log
onto our network, but I am not certain to what extent our portal
authenticates portal users.
Well that's a different problem entirely. If any random member of the general public can authenticate to the portal, she will not even have an IBM i user profile. If this is the case your portal people will need to prove authentication.
--buck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
