See also bug 1627.
This seems like it could be a huge privacy issue on Catalog computers in public libraries. It would be nice if we could set the staff and OPAC to different timeouts.
Our libraries would also like this to be developed. Thank you
We would also like to see a "refresh" timer for the Opac. We have already had issues with patrons leaving themselves logged in.
Since Koha has added a timeout function to the Self check and Self return systems, which seem to work on the Opac side (not the intranet side) shouldn't this be an easy enhancement/bug to fix now?
If we can't make it separate sessions easily, maybe we could have different timemouts for users with permissions and without? Or differentiate using the 'staff' patron category setting. So normal users that are only expected to use the OPAC can have a shorter timeout period than staff users working in the staff interface.
I think having a timeout difference for Staff vs. Others would be extremely useful. Our public services staff each have their own login and cycle through service desks every hour. Being able to ensure their account is logged out after a set amount of time would be helpful.
Marked bug 32385 as a dependency for this one. I think in order to have different timeouts, we need different sessions first.
(In reply to Katrin Fischer from comment #7) > Marked bug 32385 as a dependency for this one. I think in order to have > different timeouts, we need different sessions first. I was thinking about alternatives but I think you might be right. In theory, an alternative would be to change how we handle timeouts. At the moment, the session is deleted if it's timed out, but we could remove those lines and leave the cleanup to the cleanup_database.pl cronjob. If someone was working in both the staff interface and OPAC, the OPAC could time out and prompt for login while they continued working in the staff interface. Then if they log into the OPAC, both interfaces will use the new session and new session cookie. However, I wonder if a browser might accidentally overwrite the new CGISESSID with the old CGISESSID if a staff interface action happens shortly after the new OPAC login... Maybe different sessions are the way to go.
(In reply to Katrin Fischer from comment #7) > Marked bug 32385 as a dependency for this one. I think in order to have > different timeouts, we need different sessions first. Actually, thinking about this again, you would already have different sessions between the OPAC and staff interface, so long as your hostname is different, which should be 99% of Koha instances...
(In reply to David Cook from comment #9) > (In reply to Katrin Fischer from comment #7) > > Marked bug 32385 as a dependency for this one. I think in order to have > > different timeouts, we need different sessions first. > > Actually, thinking about this again, you would already have different > sessions between the OPAC and staff interface, so long as your hostname is > different, which should be 99% of Koha instances... How do you calculate that 99% ?
(In reply to Marcel de Rooy from comment #10) > (In reply to David Cook from comment #9) > > (In reply to Katrin Fischer from comment #7) > > > Marked bug 32385 as a dependency for this one. I think in order to have > > > different timeouts, we need different sessions first. > > > > Actually, thinking about this again, you would already have different > > sessions between the OPAC and staff interface, so long as your hostname is > > different, which should be 99% of Koha instances... > > How do you calculate that 99% ? Perhaps I should say 99% of commercially supported Koha instances. Even then you're right that it's a total guess based off the idea that Koha defaults to separate hostname for OPAC and staff interface when using Debian packages, and most commercial support vendors for Koha seem to use Debian packages.
(In reply to David Cook from comment #11) > (In reply to Marcel de Rooy from comment #10) > > (In reply to David Cook from comment #9) > > > (In reply to Katrin Fischer from comment #7) > > > > Marked bug 32385 as a dependency for this one. I think in order to have > > > > different timeouts, we need different sessions first. > > > > > > Actually, thinking about this again, you would already have different > > > sessions between the OPAC and staff interface, so long as your hostname is > > > different, which should be 99% of Koha instances... > > > > How do you calculate that 99% ? > > Perhaps I should say 99% of commercially supported Koha instances. Even then > you're right that it's a total guess based off the idea that Koha defaults > to separate hostname for OPAC and staff interface when using Debian > packages, and most commercial support vendors for Koha seem to use Debian > packages. You are right that different subdomains will create separate sessions, but I think the 99% is wrong. Koha used ports for a long time in its default setup and there are still reasons why you would want to do so. We do, with packages, use ports, for the installations we support. And it doesn't solve the problem here... different sessions, one timeout. How could you attach a different timeout to each?
(In reply to Katrin Fischer from comment #12) > You are right that different subdomains will create separate sessions, but I > think the 99% is wrong. Koha used ports for a long time in its default setup > and there are still reasons why you would want to do so. We do, with > packages, use ports, for the installations we support. > > And it doesn't solve the problem here... different sessions, one timeout. > How could you attach a different timeout to each? For your case, I think you'd need different cookie names for OPAC and Staff. Mostly would involve refactoring...
(In reply to David Cook from comment #13) > (In reply to Katrin Fischer from comment #12) > > You are right that different subdomains will create separate sessions, but I > > think the 99% is wrong. Koha used ports for a long time in its default setup > > and there are still reasons why you would want to do so. We do, with > > packages, use ports, for the installations we support. > > > > And it doesn't solve the problem here... different sessions, one timeout. > > How could you attach a different timeout to each? > > For your case, I think you'd need different cookie names for OPAC and Staff. > Mostly would involve refactoring... Not only for our use case - currently it's not possible to set different timeouts even if you are using different sub domains which divides the sessions.
(In reply to Katrin Fischer from comment #14) > Not only for our use case - currently it's not possible to set different > timeouts even if you are using different sub domains which divides the > sessions. I'm not 100% sure I understand what you're saying. Different subdomains have different cookies, but in Koha there is only the "timeout" syspref. Is that what you mean?
(In reply to David Cook from comment #15) > (In reply to Katrin Fischer from comment #14) > > Not only for our use case - currently it's not possible to set different > > timeouts even if you are using different sub domains which divides the > > sessions. > > I'm not 100% sure I understand what you're saying. > > Different subdomains have different cookies, but in Koha there is only the > "timeout" syspref. Is that what you mean? Yes.
(In reply to Katrin Fischer from comment #16) > (In reply to David Cook from comment #15) > > (In reply to Katrin Fischer from comment #14) > > > Not only for our use case - currently it's not possible to set different > > > timeouts even if you are using different sub domains which divides the > > > sessions. > > > > I'm not 100% sure I understand what you're saying. > > > > Different subdomains have different cookies, but in Koha there is only the > > "timeout" syspref. Is that what you mean? > > Yes. So if we added a new "opac_timeout" syspref and hooked it into the Auth system, we'd be able to have separate timeouts for OPAC and staff interface, but only for systems that have separate cookies for the OPAC and staff interface. I figure it's probably worth moving forward on that.
But how do we know if it's an OPAC or a staff side cookie? Maybe naming the cookies differently and by that allowing to really have separate sessions independent of setup would be better. One reason to use ports is to block access to the staff interface in a firewall. It's a valid configuration option.
(In reply to Katrin Fischer from comment #18) > But how do we know if it's an OPAC or a staff side cookie? Maybe naming the > cookies differently and by that allowing to really have separate sessions > independent of setup would be better. Yes that's what I was thinking. We're replace CGISESSID with KOHA_OPAC_SESSID and KOHA_STAFF_SESSID or something like that, and then depending on where the auth is being initiated the appropriate cookie name would be looked up. (That said, I think that might get complicated with the API...so something to investigate further.) > One reason to use ports is to block access to the staff interface in a > firewall. It's a valid configuration option. You mean using access control lists in a firewall? That's true. I suppose that using different ports would be the only way to do it with that setup. I often suggest restricting by IP address at the HTTP/application layer, since it's easy to due on a per-host basis, but there's certainly advantages to restricting access at lower OSI layers. It's good to know that there are other folk out there restricting access to their staff interface.
I'm going to echo other's sentiments. Ideally Patron Category would be the defining attribute for different time out requirements. We would set our self-check patron category for a longer timeout to ensure even during inactive periods the machine stays logged in. Library Staff users would have a short inactivity period defined to auto-log-out if they're not using the system.
I think the patron category is not ideal, but maybe the web based self check could get its own sessions as well, while we are at it?
(In reply to Katrin Fischer from comment #21) > I think the patron category is not ideal, but maybe the web based self check > could get its own sessions as well, while we are at it? I would support that too. Basically a way to force an auto-logoff for staff but still be able to keep our self-check machines logged in for the full day.
Hi A different timeout for staff and OPAC would be very useful