https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42523 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42523 --- Comment #2 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 198525 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198525&action=edit Bug 42523: Redirect to the original query after login Patch from commit d4a7274 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42523 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- 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.