× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.