Bug 42061 - Username not logged when using external authentication method
Summary: Username not logged when using external authentication method
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: 25.11
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-03-10 20:01 UTC by Eric Phetteplace
Modified: 2026-03-10 20:01 UTC (History)
1 user (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Crowdfunding committed: 0
Crowdfunding contact:
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Logs screenshot (95.99 KB, image/png)
2026-03-10 20:01 UTC, Eric Phetteplace
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Phetteplace 2026-03-10 20:01:35 UTC
Created attachment 195100 [details]
Logs screenshot

We use CAS authentication and today I noticed in our Authentication logs that the userid (username) field is empty in both success and failure messages for the OPAC and staff side. To recreate:

- Use CAS authentication e.g. casAuthentication and casServerUrl settings
- Turn on AuthSuccessLog and AuthFailureLog settings
- Sign in to the staff and OPAC side
- Go to the Log Viewer

Expected: Authentication log message "Valid password for USERNAME".

Actual: Authentication log message "Valid password for".

Looking at the auth code, I believe this is an issue no matter what external authentication is used, whether it's Shibboleth, LDAP, or CAS. The @return array is populated with $retuserid for these services (Auth.pm lines 2020-2069) but the logaction calls use $userid which is undefined.

Adding $userid = $retuserid after receiving a return value fixes the SuccessLog but the checkpw_* methods do not return a username when they fail, only 0, so the FailureLog would continue to have this problem.