Project

Profile

Help

Issue #761 ยป Issue #2193 - 2015-03-16T15_07_53Z.eml

rbarlow, 03/16/2015 04:07 PM

 
Return-Path: <rbarlow@redhat.com>
Received: from mi002.mc1.hosteurope.de ([80.237.138.253]) by wp245.webpack.hosteurope.de running ExIM with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1YXWcH-0008Iy-DR; Mon, 16 Mar 2015 16:07:41 +0100
Received: from mx1.redhat.com ([209.132.183.28]) by mx0.webpack.hosteurope.de (mi002.mc1.hosteurope.de) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1YXWcG-0001ec-8q for dropbox+pulp+c71e@plan.io; Mon, 16 Mar 2015 16:07:41 +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 t2GF7YCb001734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <dropbox+pulp+c71e@plan.io>; Mon, 16 Mar 2015 11:07:35 -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 t2GF7WEW028733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dropbox+pulp+c71e@plan.io>; Mon, 16 Mar 2015 11:07:34 -0400
Date: Mon, 16 Mar 2015 11:07:32 -0400
From: Randy Barlow <rbarlow@redhat.com>
To: Pulp <dropbox+pulp+c71e@plan.io>
Message-ID: <5506F1B4.40609@redhat.com>
In-Reply-To: <redmine.journal-2191.20150316132413.94c845be382b5490@plan.io>
References: <redmine.issue-761.20150315182455@plan.io>
<redmine.journal-2191.20150316132413.94c845be382b5490@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 16:07:41 +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 09:24 AM, bmbouter wrote:
> There are a lot of <stuff_here>/search/ urls in the Pulp API. The idea
> that GET and POST parameters should provide search is a good one, and
> should be applied to all search URLs, not just this one.

Agreed, I hinted at this in my comment.

> Regarding this defect, one possible backwards compatible fix would be t=
o
> reorder these statements in urls.py. The problem with that is that
> search will break if the user makes a username called 'search'.

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 exists,
as "search" will always match as a user ID, and then the View for
dealing with individual users will always be used.
> --- Please write your response above this line ---
> =

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

> There are a lot of <stuff_here>/search/ urls in the Pulp API. The idea
> that GET and POST parameters should provide search is a good one, and
> should be applied to all search URLs, not just this one.
> =

> Regarding this defect, one possible backwards compatible fix would be t=
o
> reorder these statements in urls.py. The problem with that is that
> search will break if the user makes a username called 'search'. I think=

> not having one username that isn't allowed and can be documented is
> better than having search completely break if the user makes a user
> named 'search'.
> =

> Based on that I recommend we document this as a known limitation at a
> minimum. We could also put in some validation code at the API and/or CL=
I
> level.
> =

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

> =

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

> * 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)