https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42523

--- Comment #4 from David Cook <[email protected]> ---
Looking back on bug 39055... 

So login_op is POSTed with a value of cud-login... along with all the other
inputs 

I think what you're doing in "Redirect to the original query after login" is
what I wasn't keen to do in
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39055#c6

And yet it looks like what Koha already does in the OPAC so I suppose doing it
in the staff interface could work too. We probably used to forbid it because of
CSRF type attacks in the past. 

(And I just found some other bugs in the OPAC while double-checking this...
lol)

I was just checking if POSTed requests get their parameters added to the
login... but looks like in the staff interface you'll get a CSRF error screen
and not a login screen. And in the OPAC the POSTed inputs seem to be dropped so
that's good. 

I think that I'd prefer that we saved the requested path in a session variable
to use for the redirect and then used that rather than relying on the HTML
inputs. This is actually what we do in an SSO scenario. See bug 34164. In that
case, we have to use the referrer because the login is initiated by the API
endpoint, but in this case we wouldn't need to use the referrer. We could just
take the HTTP request path, query string, and fragment and put that into a
session variable stored in the DB, which can't be manipulated in any way and is
invisible to end users.

-- 
You are receiving this mail because:
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to