Project

Profile

Help

Download (5.87 KB)

Issue #761 ยป Issue #2209 - 2015-03-16T16_41_19Z.eml

rbarlow, 03/16/2015 05:41 PM

 
Return-Path: <rbarlow@redhat.com>
Received: from mi024.mc1.hosteurope.de ([80.237.138.231]) by wp245.webpack.hosteurope.de running ExIM with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1YXY4n-0000g2-Nj; Mon, 16 Mar 2015 17:41:13 +0100
Received: from mx1.redhat.com ([209.132.183.28]) by mx0.webpack.hosteurope.de (mi024.mc1.hosteurope.de) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1YXY4m-0004k9-PC for dropbox+pulp+c71e@plan.io; Mon, 16 Mar 2015 17:41:13 +0100
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2GGf8g6006716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <dropbox+pulp+c71e@plan.io>; Mon, 16 Mar 2015 12:41:08 -0400
Received: from where.usersys.redhat.com (ovpn-113-56.phx2.redhat.com [10.3.113.56]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2GGf6S2028522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dropbox+pulp+c71e@plan.io>; Mon, 16 Mar 2015 12:41:07 -0400
Date: Mon, 16 Mar 2015 12:41:06 -0400
From: Randy Barlow <rbarlow@redhat.com>
To: Pulp <dropbox+pulp+c71e@plan.io>
Message-ID: <550707A2.5080506@redhat.com>
In-Reply-To: <redmine.journal-2198.20150316155233.21faaa35b299acb2@plan.io>
References: <redmine.issue-761.20150315182455@plan.io>
<redmine.journal-2198.20150316155233.21faaa35b299acb2@plan.io>
Subject: Re: [Pulp - Issue #761] Pulp allows "search" as a user's login ID
Mime-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Delivery-date: Mon, 16 Mar 2015 17:41:13 +0100
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Thunderbird/31.5.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-HE-Spam-Level: ----------
X-HE-Spam-Score: -10.0
X-HE-Spam-Report: Content analysis details: (-10.0 points) pts rule name
description ---- ----------------------
-------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL:
Sender listed at http://www.dnswl.org/, high trust [209.132.183.28 listed in
list.dnswl.org] -5.0 PGP_MESSAGE RAW: Contains a PGP signed or encrypted
message
X-HE-SPF: PASSED
Envelope-to: dropbox+pulp+c71e@plan.io

On 03/16/2015 11:52 AM, bmbouter wrote:
> You're right it is worse then that. Is the fix for this issue to
> disallow 'search' as a user's login ID in the API? What about the CLI?
> Also how does the fix for this similar or different from a fix needed
> for #760 <https://pulp.plan.io/issues/760>?

I think the fix is either to change the URL structure (which requires
waiting until 3.0.0, or to disallow "search" as the user's login ID
until then. I don't feel strongly one way or the other, but I wanted to
at least document the issue via a ticket.

#760 is not really related to this. I did try to create a user named
"search" as an example there, but it turns out that no user of any name
can be created. I mentioned it here because I was unable to verify for
sure that it was true that a user named "search" can be created. After
reviewing some code, I do believe it's possible, but I wanted to just
try it to find out.
> --- Please write your response above this line ---
> =

> Issue #761 has been updated by bmbouter.
> =

> rbarlow wrote:
> =

> Agreed, I hinted at this in my comment.
> =

> Indeed you did. I created #763 <https://pulp.plan.io/issues/763> so tha=
t
> we could track that broader effort and set backwards incompatible =3D T=
rue.
> =

> I believe it's worse than that - if we reorder the URLs, it will be=

> impossible to search regardless of whether a user named search exis=
ts,
> as "search" will always match as a user ID, and then the View for
> dealing with individual users will always be used.
> =

> You're right it is worse then that. Is the fix for this issue to
> disallow 'search' as a user's login ID in the API? What about the CLI?
> Also how does the fix for this similar or different from a fix needed
> for #760 <https://pulp.plan.io/issues/760>?
> =

> -----------------------------------------------------------------------=
-
> =

> =

> Issue #761: Pulp allows "search" as a user's login ID
> <https://pulp.plan.io/issues/761#change-2198>
> =

> * Author: rbarlow
> * Status: NEW
> * Priority: Normal
> * Assignee:
> * Category: API
> * Sprint/Milestone:
> * Severity: Medium
> * Triaged: No
> * Target Release:
> * Backwards Incompatible: No
> * Tags: Easy Fix
> * Version: Master
> * QA Contact:
> * Bugzilla: =

> =

> I noticed that we have a problem with our REST interface's URL
> structure. In our urls.py, the following two lines are present:
> =

> | url(r'^v2/users/search/$', users.UserSearchView.as_view(),
> name=3D'user_search'),
> url(r'^v2/users/(?P<login>[^/]+)/$', users.UserResourceView.as_view=
(), name=3D'user_resource')
> |
> =

> If there were a user named "search", it would be impossible to retrieve=

> that user because the first URL would match and it would be assumed tha=
t
> the REST call was requesting a search, rather than a user named "search=
".
> =

> However, I did not see anything in our user creation code preventing a
> user named "search" from being created. However, I was unable to test
> this, due to #760 <https://pulp.plan.io/issues/760>.
> =

> -----------------------------------------------------------------------=
-
> =

> You have received this notification because you have either subscribed
> to or are involved in a project on Pulp Planio.
> To change your notification preferences, please click here:
> https://pulp.plan.io/my/account
> =

> =

> =

> This notification was cheerfully delivered by <https://plan.io/>
> =

> Planio <https://plan.io/>
> =



-- =

Randy Barlow
    (1-1/1)