Bug 41442

Summary: check_api_auth can fail to authenticate service user if userid is not same as cardnumber
Product: Koha Reporter: Galen Charlton <gmcharlt>
Component: Architecture, internals, and plumbingAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: minor    
Priority: P5 - low    
Version: unspecified   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Galen Charlton 2025-12-12 16:56:20 UTC
If check_api_auth() ends up doing internal authentication of a service user whose userid is not the same as its cardnumber, the password can get successfully validated but the overall authentication can fail.

This is because, like other authentication pathways, it's possible to pass a cardnumber to identify the user to check_api_auth() and have checkpw() successful validate the password. However, after checkpw() is called, the authentication must pass haspermission(), which _requires_ that it always be passed the userid.

Other authentication pathways will result in $userid getting set correctly before it's passed to haspermission(), but check_api_auth() doesn't currently do that.

One way that this can manifest is that if you have set up a service user for the OCLC Connexion importer whose cardnumber is not the same as the userid, the importer's attempts to authenticate itself to Koha can subtly fail.