On Tue, Aug 21, 2018 at 3:58 PM, Tim Fathers <X700-IX2J@xxxxxxxxxxx> wrote:

I'd agree with what's already been said, I don't think the right approach
is to try to change the user of the job, but to use a single database
connection profile. If you want non-IBM i users to be able to use the
system you will in any case have to have a shared user id that these people
use won't you?

yes, the non-IBM i users would use a share profile that had limited
rights. Then, those validation list users who were associated with a user
profile, they would run as their specific user profiles. But not possible,
since a validation list cannot be linked to the QSYGETPH API.

having the stored procedure check that the validation list user has
authority to a table also seems problematic in terms of making sure
malicious code is not calling the SP.

It's not problematic if you pass the token to the stored procedure and
then have the stored procedure validate it because only a previously
authenticated user would have a valid token. Of course, passing the user id
and having the stored procedure trust it blindly would be a bad idea!

I like it. Just that I do not have a way to create tokens. Just using
validation list to authenticate users.

For example, all our stored procedures have this line of code at the start:

set currentUser = WAA_UDF_CheckAuth(SYSIBM.ROUTINE_SCHEMA,

The current CURRENT CLIENT_USERID is set during the database connect to
the token not the user id. With the JDBC driver it's done like this, but
it's a long time since I fiddle with PHP so Ican't remember how you'd do
the same thing.

con.setClientInfo("ClientUser", authToken);

good to know. Will be thinking about doing something similar. Just worry
that I will do something wrong or incomplete, with the result being
security holes in the application.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 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.