Actually there is a reason to change the last signed on date: auditability.
So where is this password being utilized and why? If you are not changing the last signed on date why do you want to check a password against a profile?
As far as the web service goes you don't have to operate under the swapped to profile. You do the following and you are good to go.
1. Get a profile handle for your current user. You'll need it later.
2. Get a profile handle for the profile you want to check the password for. When using the QSYGETPH or QsyGetProfileHandle APIs provide the password.
Your service has to have *USE authority for the profile to do so. If the password is not correct CPF22E2 will be in the error code and you are done.
3. Swap to the profile you just obtained a handle for (QWTSETP api).
4. Run the QSYCHGPR API. Always nice to know the last time someone access the system. This is so fast you won't even notice it.
5. Release the profile you just swapped to (QSYRLSPH api).
6. Swap back to the profile handle you obtained in step 1.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Tuesday, June 10, 2014 10:52 AM
To: Midrange Systems Technical Discussion
Subject: Re: Password checking for web service calls
On 6/10/14 10:30 AM, Monnier, Gary wrote:
Have you thought of using the QSYCHGPR (Change last signed on date)
API in conjunction with a profile swap/unswap?
There is no profile swap/unswap involved. In this, or in any other client-server product we've developed. That's why I've never actually used the profile handle returned from QSYGETPH. And the indirect way we spawn child-server jobs virtually guarantees that the 20k limit on any given job's profile handles can never be approached, much less exceeded.
The problem is that this doesn't apply to a web service (which, unlike a child-server job, has no real reason to run under the user's profile).
And what does a call to an API that updates the last-signed-on date have to do with password checking, anyway?
--
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
