Tweet
Qsygetph
We use QSYGETPH . Software external to the IBMi sends over the user's ID and password and we confirm that it is valid and allowed to update the data they are trying to update. Our security team is planning to change the password requirements to include a longer password and require special characters. My co-worker and I have been discussing whether or not we can change our programming to allow a longer password before the security team does their thing.
Everything in IBM's information (https://www.ibm.com/docs/en/i/7.4?to.../QSYGETPH.html) makes sense to me, except the part I've pasted below. If you were facing this change, what would you be researching? I can't have these processes just die because we have multiple manufacturing facilities that rely on them.
Any thoughts will be appreciated.
FROM: https://www.ibm.com/docs/en/i/7.4?to.../QSYGETPH.html
Everything in IBM's information (https://www.ibm.com/docs/en/i/7.4?to.../QSYGETPH.html) makes sense to me, except the part I've pasted below. If you were facing this change, what would you be researching? I can't have these processes just die because we have multiple manufacturing facilities that rely on them.
Any thoughts will be appreciated.
Usage Notes
Profile handles are a limited resource; it is possible to run out of handles. To guarantee that you always have a profile handle to switch back to, it is recommended that you get a profile handle for both the current thread and the user profile to which you plan to switch. If for some reason you cannot do this, and if you cannot get a profile handle that will allow you to switch back, then it probably is safest to end the thread or job.
The CCSID parameter on this API can lead to potential problems if coded with inconsistent CCSID values. Passwords created using the CRTUSRPRF, CHGUSRPRF, and CHGPWD CL commands, as well as the QSYCHGPW API (when called without passing the CCSID parameter), while the system is running password level 0 or 1 are created using CCSID 37. Passwords created using these CL commands and the QSYCHGPW API (without the CCSID parameter specified) when running password level 2 or 3 are created using the default job CCSID. Using variant characters $, @ and #, as well as other variant characters, in a user password may result in inconsistencies when converting from one CCSID to another. When calling this API on password level 0 or 1, CCSID 37 should be specified unless the password string is in a known CCSID. When calling this API on password level 2 or 3, pass the default job CCSID unless the password string is in a known CCSID.
Profile handles are a limited resource; it is possible to run out of handles. To guarantee that you always have a profile handle to switch back to, it is recommended that you get a profile handle for both the current thread and the user profile to which you plan to switch. If for some reason you cannot do this, and if you cannot get a profile handle that will allow you to switch back, then it probably is safest to end the thread or job.
The CCSID parameter on this API can lead to potential problems if coded with inconsistent CCSID values. Passwords created using the CRTUSRPRF, CHGUSRPRF, and CHGPWD CL commands, as well as the QSYCHGPW API (when called without passing the CCSID parameter), while the system is running password level 0 or 1 are created using CCSID 37. Passwords created using these CL commands and the QSYCHGPW API (without the CCSID parameter specified) when running password level 2 or 3 are created using the default job CCSID. Using variant characters $, @ and #, as well as other variant characters, in a user password may result in inconsistencies when converting from one CCSID to another. When calling this API on password level 0 or 1, CCSID 37 should be specified unless the password string is in a known CCSID. When calling this API on password level 2 or 3, pass the default job CCSID unless the password string is in a known CCSID.
Comment