[PATCH 1 of 1 v2] login: preserve GET arguments throughout login redirection (issue #104)

Mads Kiilerich mads at kiilerich.com
Sat Jun 6 16:28:46 EDT 2015


On 06/04/2015 07:40 PM, Thomas De Schampheleire wrote:
> On June 4, 2015 6:55:30 PM CEST, Mads Kiilerich <mads at kiilerich.com> wrote:
>> On 05/31/2015 01:41 PM, Thomas De Schampheleire wrote:
>>> # HG changeset patch
>>> # User Thomas De Schampheleire <thomas.de.schampheleire at 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.

/Mads


More information about the kallithea-general mailing list