We just discovered that staff accounts can be used for staff logins, SIP, API, etc even if they are expired. The question we don't have an answer to is; should this be allowed? We could prevent staff logins for expired accounts, or perhaps add a new 'enabled' column to explicitly enable/disable accounts from logging in to Koha. Right now, the only way to disable an account without deleting it is to remove user permissions, which may be non trivial if the account has complicated permissions and may need to be 'restored' in the future. What do you all think?
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.