Bug 15816 - Timeout login redirects to home page
Summary: Timeout login redirects to home page
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: Main
Hardware: All All
: P3 major (vote)
Assignee: Jesse Weaver
QA Contact: Testopia
URL:
Keywords:
: 15945 16250 16632 (view as bug list)
Depends on: 15005
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-13 16:28 UTC by Ian Palko
Modified: 2019-06-27 09:24 UTC (History)
11 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 15816: Redirect back to correct page after login (4.39 KB, patch)
2016-05-06 20:00 UTC, Jesse Weaver
Details | Diff | Splinter Review
Bug 15816: Redirect back to correct page after login (4.46 KB, patch)
2016-05-09 12:50 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15816: Redirect back to correct page after login (4.52 KB, patch)
2016-05-09 13:55 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Palko 2016-02-13 16:28:21 UTC
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.
Comment 1 Jonathan Druart 2016-02-16 09:14:56 UTC
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!
Comment 2 Jonathan Druart 2016-03-01 08:20:52 UTC
*** Bug 15945 has been marked as a duplicate of this bug. ***
Comment 3 Jonathan Druart 2016-04-08 09:37:39 UTC
It would be great to have this one fixed for the next release.
Tomas, any ideas how we can fix it?
Comment 4 Ian Palko 2016-04-23 14:00:29 UTC
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 ...
Comment 5 Katrin Fischer 2016-04-27 11:39:33 UTC
*** Bug 16250 has been marked as a duplicate of this bug. ***
Comment 6 Katrin Fischer 2016-04-27 11:40:00 UTC
This is a big problem for the OPAC as well - see comments on bug 16250.
Comment 7 Jesse Weaver 2016-05-06 20:00:08 UTC Comment hidden (obsolete)
Comment 8 Jesse Weaver 2016-05-06 20:00:54 UTC
This isn't a beautiful fix, but works around the problem without requiring Apache config changes or new Perl modules.
Comment 9 Jonathan Druart 2016-05-09 12:50:49 UTC Comment hidden (obsolete)
Comment 10 Jonathan Druart 2016-05-09 13:41:10 UTC
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?
Comment 11 Tomás Cohen Arazi 2016-05-09 13:55:06 UTC
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>
Comment 12 Jesse Weaver 2016-05-09 17:06:14 UTC
(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.
Comment 13 Kyle M Hall 2016-05-13 12:38:56 UTC
Pushed to master for the 16.05 release. Thanks Jesse!
Comment 14 Christopher Brannon 2016-05-13 15:27:54 UTC
Any chance this will work on 3.22?  Would like to be able to fix this on our server.
Comment 15 Julian Maurice 2016-05-16 07:13:53 UTC
Patch pushed to 3.22.x, will be in 3.22.7
Comment 16 Christopher Brannon 2016-06-08 22:26:03 UTC
Thank you!
Comment 17 Marc Véron 2017-02-19 09:23:06 UTC
*** Bug 16632 has been marked as a duplicate of this bug. ***