https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28822 --- Comment #10 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Agnes Rivers-Moore from comment #9)
We are seeing this often but it's not from a checkout - it is from logging in to a remote 3rd party service that uses SIP to check the borrower status. In my example - Overdrive - the Koha member logs in to access their account in Overdrive, Overdrive queries Koha with SIP to check the member patron record is not expired or suspended. There is no checkout process associated with Koha, but somehow that gets recorded as a login attempt (either an unsuccessful one, or one not cancelled by a log out). Overdrive checkout then proceeds in the Overdrive member account. The same may be happening with other third party SIP connections that check status. To recreate - set up Overdrive to confirm members status using SIP. Create a Koha account. Create an Overdrive account using the member barcode. Log in to Libby using the patron barcode. In Koha, check the current logins = 1. Log out of Libby, login count in Koha remains at 1. Log in to Libby - check login count increases to 2. I hope I have explained clearly. We do want the SIP logins to be registered in Koha - there was a bug/enhancement about that as there was no record of 'last seen' in Koha from those external SIP transactions. That was worked on, so that the last seen would update for external SIP logins.
Looks like you need someone who knows these third party tools. What I do see in the Koha code, is that patron_status and patron_info requests when accompanied by a patron password will lead to a verification that might increase login_attempts when it is wrong. Note that patron_info does not need it to provide output. In other words: Does Overdrive perhaps send a empty password string for a patron info request? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.