Since ILS-DI (which specifically means the AuthenticatePatron verb) is an option that can be selected for TrackLastPatronActivityTriggers, I would expect the validateUserAndPassword of the REST API to also contribute to updating borrowers.lastseen. Since there is no separate option for activalting it, I thought maybe the REST API is considered so much "core" to Koha that the logins are tracked when "Logging in" is activated as an option for TrackLastPatronActivityTriggers. But it looks like it is not. To reproduce in KTD: TrackLastPatronActivityTriggers = [Select all] RESTBasicAuth = Enable Check the lastseen value of the "koha" user in the database: select borrowernumber, lastseen from borrowers where borrowernumber = 51; The value should be NULL, or some past timestamp. Run this script: https://wiki.koha-community.org/wiki/REST_API:_Checking_username_and_password Check the lastseen value of the "koha" user again. I would expect it to have been updated when the script ran, but it is not. Not sure if validateUserAndPassword should be considered as just another way of "Logging in", or if it should be a separate option for TrackLastPatronActivityTriggers, but the latter would give maximum flexibility.
Hmm, makes sense, although I'd say the problem probably goes deeper. That is, the solution isn't to put it in the REST API but rather at the lower level successful authentication, so that it applies to all successful authentications regardless of controller.
Currently, the REST API 'patron login' is actually doing a verification of a username and password to be sure they are correct (checkpw). This is only a portion of the full authentication process in C4::Auth. Additionally, a 'verification' via API is not a full 'login' to Koha, but rather a login to whatever application is using the API (in most cases). I can see use cases when knowing when a patron is doing a full login to Koha versus when they are being verified via an API call. I agree that a larger rework may be needed for the lower level authentication system to accept a variety of 'login' paths, but for the time being, adding an update_lastseen option for the API is a very trivial addition for a big benefit.
Created attachment 185532 [details] [review] Bug 36536: Make REST APIs validateUserAndPassword update borrowers.lastseen This patch added the option to update borrowers.lastseen when a patron username and password is verified via the REST API. This can be enabled or disabled selectively using the TrackLastPatronActivityTriggers system preference using the [ ] Patron authentication via API option.. To test: 1. Create a new user, ensuring to set the Username and password fields. *Import to do this first* 2. Edit the TrackLastPatronActivityTriggers syspref and check 'login 3. Ensure the RESTBasicAuth syspref is set to Enable. 4. Check the lastseen date of your new user using a SQL report SELECT borrowernumber, userid, lastseen FROM borrowers WHERE userid = 'USERNAME' (Replace USERNAME with your chosen username for the new patron) 5. The lastseen for your new user should be null 6. Run the attached api_verify_lastseen.pl test script **Change P_USERNAME and P_PASSWORD to the username and password of your new user. (script contains expected output for successful verification) 7. Re-check the lastseen date of your new user again via SQL (step 4) The lastseen should still be null. 8. Apply Patch 9. Edit the TrackLastPatronActivityTriggers syspref and check the '[ ] Patron authentication via API' option 10. Rerun the api_verify_lastseen.pl 11. Re-check the lastseen date of your new user again via SQL (step 4) The lastseen should now be updated to the time of the last script run. For good measure: 12. Edit the TrackLastPatronActivityTriggers syspref and **UNcheck** the '[ ] Patron authentication via API' option 13. Rerun the api_verify_lastseen.pl 14. Re-check the lastseen date of your new user again via SQL (step 4) The lastseen should have remained the same as previous. Sponsored-by: Westlake Porter Public Library <https://westlakelibrary.org>
Created attachment 185534 [details] TESTING SCRIPT: api_verify_lastseen.pl Perl script for testing an API call to verify patron username and password. *Not part of patch*
Created attachment 185582 [details] [review] Bug 36536: Make REST APIs validateUserAndPassword update borrowers.lastseen This patch added the option to update borrowers.lastseen when a patron username and password is verified via the REST API. This can be enabled or disabled selectively using the TrackLastPatronActivityTriggers system preference using the [ ] Patron authentication via API option.. To test: 1. Create a new user, ensuring to set the Username and password fields. *Import to do this first* 2. Edit the TrackLastPatronActivityTriggers syspref and check all options. 3. Ensure the RESTBasicAuth syspref is set to Enable. 4. Check the lastseen date of your new user using a SQL report SELECT borrowernumber, userid, lastseen FROM borrowers WHERE userid = 'USERNAME' (Replace USERNAME with your chosen username for the new patron) NOTE: **Ensure the cache expiry of the SQL report is set to 0** 5. The lastseen for your new user should be null 6. 'restart_all' Koha services to clear plack cache. 7. Run the attached api_verify_lastseen.pl test script **Change P_USERNAME and P_PASSWORD to the username and password of your new user. (script contains expected output for successful verification) 8. Re-check the lastseen date of your new user again via SQL (step 4) The lastseen should still be null. 9. Apply Patch 10. 'restart_all' Koha services 11. Edit the TrackLastPatronActivityTriggers syspref and check the '[ ] Patron authentication via API' option 12. Rerun the api_verify_lastseen.pl 13. Re-check the lastseen date of your new user again via SQL (step 4) The lastseen should now be updated to the time of the last script run. For good measure: 14. Edit the TrackLastPatronActivityTriggers syspref and **UNcheck** the '[ ] Patron authentication via API' option 15. 'restart_all' Koha services to clear plack cache. 16. Rerun the api_verify_lastseen.pl 17. Re-check the lastseen date of your new user again via SQL (step 4) The lastseen should have remained the same as previous. Sponsored-by: Westlake Porter Public Library <https://westlakelibrary.org>