|
What in the <censored> was IBM thinking when they broke the <blasphemy> <obscenity> <vulgarity> QSYGETPH API in V5R3, such that it now requires <censored> parameters that didn't even <censored> exist when the API was first defined?
I agree that they should not have made the 4-6th parameters manditory. I don't even understand why they did it, it seems like the V5R2 setup would've worked just fine on V5R3 and not broken backward compatibility.
However, I think what was happening was that people were using this API for their custom written server software. A GUI front-end would ask the user for a userid/password and it'd be passed over a network and checked with QSYGETPH. Lots of software like this made it into production... then a hacker realized that he could simply supply *CURRENT and *NOPWDCHK for the GUI app, and he'd get in without having to know his password.
So IBM split the API into two different ones called QsyGetProfileHandle and QsyGetProfileHandleNoPwd. And the OPM front-end (QSYGETPH) needed to be similarly protected, and the way they did that was to make parms 5-6 manditory when a password is supplied. And required that they be NOT passed when a special value is used. That way, each program that calls QSYGETPH can only do one or the other at compile time.
So, it's a tough issue. Do you assume that all customers using QSYGETPH are savvy enough to check the parms for special values before calling the API? Or is it better to make the API secure, even if that breaks compatibility?
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.
midrange.com
