| Summary: | Expired staff accounts can still log in to Koha staff intranet, SIP, API, etc. | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Kyle M Hall (khall) <kyle> |
| Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | dcook, didier.gautheron, janet.mcgowan, madamyk, nglhelpdesk, r.delahunty |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Kyle M Hall (khall)
2020-11-03 15:48:01 UTC
Hi, Isn't changing password good enough? Doing it the Unix way , with an invalid password should be better though. A changed password can't be queried, I like the idea of an enable/disable functionality for the permissions. You would still want to allow OPAC logins, but block staff. Locally, I think that we block all expired users from logging in. We do already have the "debarred" column. We use that for some local customizations too where we want to block people from logging in. (In reply to David Cook from comment #3) > Locally, I think that we block all expired users from logging in. > > We do already have the "debarred" column. We use that for some local > customizations too where we want to block people from logging in. Although I suppose being debarred until 9999-12-31 isn't exactly the same as "disabled" heh. (In reply to Katrin Fischer from comment #2) > A changed password can't be queried, I like the idea of an enable/disable > functionality for the permissions. You would still want to allow OPAC > logins, but block staff. We could query it if we changed the password field to "!". I feel that's something that Koha sometimes does? (In reply to David Cook from comment #5) > (In reply to Katrin Fischer from comment #2) > > A changed password can't be queried, I like the idea of an enable/disable > > functionality for the permissions. You would still want to allow OPAC > > logins, but block staff. > > We could query it if we changed the password field to "!". I feel that's > something that Koha sometimes does? I'm not seeing the in the code with some basic grepping. The problem I see with that is, again, that it changes data about the user. The user's password is then lost, and without additional data ( public note, private note ), the reason for the password being changed would be unknown. (In reply to Kyle M Hall from comment #6) > (In reply to David Cook from comment #5) > > (In reply to Katrin Fischer from comment #2) > > > A changed password can't be queried, I like the idea of an enable/disable > > > functionality for the permissions. You would still want to allow OPAC > > > logins, but block staff. > > > > We could query it if we changed the password field to "!". I feel that's > > something that Koha sometimes does? > > I'm not seeing the in the code with some basic grepping. The problem I see > with that is, again, that it changes data about the user. The user's > password is then lost, and without additional data ( public note, private > note ), the reason for the password being changed would be unknown. Hmm maybe that's something from the past then. I thought we used to set the password field to ! when we didn't have a password for users. Or maybe that's something we did locally... But I agree about the reasons not to do it. This badly needs a restriction on accounts for Koha access via the staff client. At the moment the only option would appear to be removing the ability to log in from the the permissions. The ability to restrict access based on Patron Category would be the preferred option. We use external authentication rather than using Koha authentication so if the removal of access were to be based on the Koha password, that would not work for us. Perhaps the option to temporary restrict accounts which access the staff client would the preferred priority. There are probably numerous requirements for non Library staff/patrons which would be almost impossible to standardise. As mentioned the only way around limiting accounts which access the client is to remove the ability to log in via the permissions. I'd be interested to see where this sits with Cyber Essentials/internal auditing. (In reply to Ray Delahunty from comment #9) > We use external authentication rather than using Koha authentication so if > the removal of access were to be based on the Koha password, that would not > work for us. That's a good point. If I recall correctly, locally we block SIP logins if the user is expired. So I think this could actually just be handled during an authorization step. We just need to add some business logic alongside the account lockout feature I imagine. (In reply to David Cook from comment #12) > So I think this could actually just be handled during an authorization step. That is, they've proven they are who they say they are during the authentication step. But expired users aren't authorized to use Koha, so they must take steps out-of-band to no longer be expired, so that they can be re-authorized. |