Bug 41442 - check_api_auth can fail to authenticate service user if userid is not same as cardnumber
Summary: check_api_auth can fail to authenticate service user if userid is not same as...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low minor
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-12-12 16:56 UTC by Galen Charlton
Modified: 2025-12-12 16:56 UTC (History)
0 users

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.