|
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?
I like it. Just that I do not have a way to create tokens. Just using
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!
For example, all our stored procedures have this line of code at the start:
set currentUser = WAA_UDF_CheckAuth(SYSIBM.ROUTINE_SCHEMA,
SYSIBM.ROUTINE_SPECIFIC_NAME,
CURRENT CLIENT_USERID);
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);
As an Amazon Associate we earn from qualifying purchases.
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.