On Sat, Jun 6, 2015 at 10:28 PM, Mads Kiilerich <m...@kiilerich.com> wrote: > On 06/04/2015 07:40 PM, Thomas De Schampheleire wrote: >> >> On June 4, 2015 6:55:30 PM CEST, Mads Kiilerich <m...@kiilerich.com> >> wrote: >>> >>> On 05/31/2015 01:41 PM, Thomas De Schampheleire wrote: >>>> >>>> # HG changeset patch >>>> # User Thomas De Schampheleire <thomas.de.schamphele...@gmail.com> >>>> # Date 1432065035 -7200 >>>> # Tue May 19 21:50:35 2015 +0200 >>>> # Node ID 20bf71e88042ca1f519c4ee711fa436564360755 >>>> # Parent 579110ca5178f13254e7e4c7b6043767a11b92a2 >>>> login: preserve GET arguments throughout login redirection (issue >>> >>> #104) >>>> >>>> When redirecting a user to the login page and while handling this >>> >>> login and >>>> >>>> redirecting to the original page, the GET arguments passed to the >>> >>> original >>>> >>>> URL are lost through the login redirection process. >>>> >>>> For example, when creating a pull request for a specific revision >> >> >from the >>>> >>>> repository changelog, there are rev_start and rev_end arguments >>> >>> passed in >>>> >>>> the URL. Through the login redirection, they are lost. >>>> >>>> Fix the issue by passing along the GET arguments to the login page, >>> >>> in the >>>> >>>> login form action, and when redirecting back to the original page. >>>> Tests are added to cover these cases, including tests with unicode >>> >>> GET >>>> >>>> arguments. >>>> >>>> diff --git a/kallithea/controllers/login.py >>> >>> b/kallithea/controllers/login.py >>>> >>>> --- a/kallithea/controllers/login.py >>>> +++ b/kallithea/controllers/login.py >>>> @@ -102,6 +102,11 @@ class LoginController(BaseController): >>>> came_from = url('home') >>>> return came_from >>>> + def _redirect_to_origin(self, origin, headers=None): >>>> + '''redirect to the original page, preserving any get >>> >>> arguments given''' >>>> >>>> + request.GET.pop('came_from', None) >>>> + raise HTTPFound(location=url(origin.encode('utf-8'), >>> >>> **request.GET), headers=headers) >>> >>> I wonder, why is it correct to hardcode utf-8 here? >> >> Do you mean to just call encode without argument? Or do you don't encode >> itself? >> >> Without it, it doesn't work, but I welcome any attempts to do it >> differently. The tests should cover everything so feel free to experiment... > > > It seems like the answer is that anything in GET already is URL encoded and > thus always ascii and it is more correct to use something like safestr. I > applied something like that ... and some other minor tweaks.
Thanks for looking into it! _______________________________________________ kallithea-general mailing list kallithea-general@sfconservancy.org http://lists.sfconservancy.org/mailman/listinfo/kallithea-general