On the staff client, when the session times out, or the user is asked to login again, the login always redirects to the home page. Formerly (as of 3.18.6 from which we upgraded to 3.22.1), it would redirect back to the page requested. --------- Example of former behavior: Login has timed out. User clicks link for a new biblio record from z39.50 (Cataloging). Pop-up search window opens, but asks for a login. Once logged in the z39.50 search form is shown. Example of present behavior: Login has timed out. User clicks link for a new biblio record from z39.50 (Cataloging). Pop-up search window opens, but asks for a login. Once logged in the staff home page is shown in the pop-up window. Behavior is the same for other pages as well. It seems the requested page (which appears in the address bar) is not passed to the login form (which is in mainpage.pl) and instead mainpage.pl is shown. Not a deal breaker, but annoying to have to login from scratch (or in another window) to a continue working on a record you were working on yesterday, or continue a session. I suspect Bug 15005.
Hi Ian, Yes I have noticed that, and yes, it's caused by bug 15005. I have talked with Tomas about this bug but we have not found a solution yet. Thanks for reporting the bug anyway!
*** Bug 15945 has been marked as a duplicate of this bug. ***
It would be great to have this one fixed for the next release. Tomas, any ideas how we can fix it?
I noticed today that when things timeout and the login screen is presented the URL shown by the browser is the correct that should have appeared if there were no timeout. If that is the case, it should be able to be grabbed by a js or perl script and then passed to the login script as a string. After login, if the string exists, the script would replace the homepage redirect with the string. That might add an inherent security flaw as if one could inject a variable, one could maliciously redirect, but I imagine there are ways around that. I haven't looked at the guts of the scripts to see if this is possible without heavy rework, but perhaps it's an idea ... or perhaps you've thought of it already ... either way, for what it's worth ...
*** Bug 16250 has been marked as a duplicate of this bug. ***
This is a big problem for the OPAC as well - see comments on bug 16250.
Created attachment 51300 [details] [review] Bug 15816: Redirect back to correct page after login This uses a hacky but simple method to get the correct script name under proxied packaged Plack. Test plan: 1) Log out of both the OPAC and staff side. 2) Try to access a page that requires login (opac-reserve.pl is a good one for the OPAC), then log in. 3) You will be redirected back to mainpage.pl or opac-user.pl. 4) Repeat above for both staff side and OPAC. 5) Apply patch. 6) Repeat steps 1-4; you should be redirected back to the original page you were on. 7) Repeat the above for both a traditional CGI and kohadevbox/package Plack installation.
This isn't a beautiful fix, but works around the problem without requiring Apache config changes or new Perl modules.
Created attachment 51323 [details] [review] Bug 15816: Redirect back to correct page after login This uses a hacky but simple method to get the correct script name under proxied packaged Plack. Test plan: 1) Log out of both the OPAC and staff side. 2) Try to access a page that requires login (opac-reserve.pl is a good one for the OPAC), then log in. 3) You will be redirected back to mainpage.pl or opac-user.pl. 4) Repeat above for both staff side and OPAC. 5) Apply patch. 6) Repeat steps 1-4; you should be redirected back to the original page you were on. 7) Repeat the above for both a traditional CGI and kohadevbox/package Plack installation. Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment on attachment 51323 [details] [review] Bug 15816: Redirect back to correct page after login Review of attachment 51323 [details] [review]: ----------------------------------------------------------------- ::: C4/Auth.pm @@ +2055,5 @@ > + > +sub _get_script_name { > + # This is the method about.pl uses to detect Plack; now that two places use it, it MUST be > + # right. > + if ( ( any { /(^psgi\.|^plack\.)/i } keys %ENV ) && $ENV{SCRIPT_NAME} =~ m,^/(intranet|opac)(.*), ) { Jesse, why do we need to parse SCRIPT_NAME?
Created attachment 51324 [details] [review] Bug 15816: Redirect back to correct page after login This uses a hacky but simple method to get the correct script name under proxied packaged Plack. Test plan: 1) Log out of both the OPAC and staff side. 2) Try to access a page that requires login (opac-reserve.pl is a good one for the OPAC), then log in. 3) You will be redirected back to mainpage.pl or opac-user.pl. 4) Repeat above for both staff side and OPAC. 5) Apply patch. 6) Repeat steps 1-4; you should be redirected back to the original page you were on. 7) Repeat the above for both a traditional CGI and kohadevbox/package Plack installation. Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(In reply to Jonathan Druart from comment #10) > Comment on attachment 51323 [details] [review] [review] > Bug 15816: Redirect back to correct page after login > > Review of attachment 51323 [details] [review] [review]: > ----------------------------------------------------------------- > > ::: C4/Auth.pm > @@ +2055,5 @@ > > + > > +sub _get_script_name { > > + # This is the method about.pl uses to detect Plack; now that two places use it, it MUST be > > + # right. > > + if ( ( any { /(^psgi\.|^plack\.)/i } keys %ENV ) && $ENV{SCRIPT_NAME} =~ m,^/(intranet|opac)(.*), ) { > > Jesse, why do we need to parse SCRIPT_NAME? This is to make sure that we're not needlessly applying the fix; a local testing setup with plackup and (I think) the multi-host work on bug 15562 don't need this fix.
Pushed to master for the 16.05 release. Thanks Jesse!
Any chance this will work on 3.22? Would like to be able to fix this on our server.
Patch pushed to 3.22.x, will be in 3.22.7
Thank you!
*** Bug 16632 has been marked as a duplicate of this bug. ***