Ideally, there aren't any publicly accessible, production sites set up in the way described below, however there is a bypass of 2FA if there are (though this would still require a compromised PIN). I have a test environment of Koha on a local-network server. When I first set it up, I made the staff client address the IP of the server, and the OPAC the same IP at a specific port (xxx.xxx.xxx.xxx:8081). I've never gotten around to correcting that, and consequently when I'm logged into the staff client it also considers me to be logged in to the OPAC, and visa versa (at that point I can go to either the IP or the IP+Port to go between them). I set up two factor authentication on a staff account, which is working correctly when I log into the staff client. As expected, when I log into the OPAC there's no 2FA code requested, however I can then just go to the base IP (the staff client) and I will be logged into the staff client without having to deal with 2FA.
Not sure this is considered a bug. It's a configuration issue in my opinion.
(In reply to Jonathan Druart from comment #1) > Not sure this is considered a bug. It's a configuration issue in my opinion. I'm inclined to say the same.
No, this is not a bug. This is design :) It always worked that way already. If you log in via the OPAC, you have a session (+cookie) that allows you access to staff too [when having sufficient permissions] when sharing the same domain between OPAC and staff. So, 2FA works here as expected. If you do not want that to happen, it is indeed a matter of configuration. Make sure that OPAC and staff are not using the same domain. They wont share the cookie, problem solved. Thats not the final word imo though. We already have reports asking for e.g. separate timeout settings for OPAC and staff/intranet sessions. We should imo create a separate OPAC and staff session and session cookie. This probably wont happen before refactoring/rewriting C4::Auth? I couldnt find a report for separating the session so quickly, so I opened a new one. But I think that it must have been submitted already in the past, only with some other terms or so.. Bug 32385. Closing this one.
Fair enough, just wanted make sure it was known if it wasn't already. Sounds good on the new bug about the session cookies.