Uses authenticated access to Launchpad when anonymous will do

Bug #906846 reported by Jonathan Lange
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Distributed Development
New
Undecided
Unassigned

Bug Description

Much of what lp:udd does with Launchpad is read-only: add-import-jobs, list-packages etc. All of this could be done using anonymous Launchpad access. The only things that need write access to lp over the API are delete-branches-from-lp and set-official.

Using read-only access when only read-only access is needed prevents accidental or malicious writes, and simplifies configuration for deployments that don't need write access.

Tom Haddon (mthaddon)
tags: added: canonical-webops-ca
Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 906846] Re: Uses authenticated access to Launchpad when anonymous will do

It would also make it harder to tell that it is udd doing things,
which is quite nice for us. Please consider at a minimum setting a
custom user agent if you start using anonymous access. However,
ideally, I'd say keep using authenticated access.

Revision history for this message
Jonathan Lange (jml) wrote :

On Tue, Dec 20, 2011 at 10:28 PM, Robert Collins
<email address hidden> wrote:
> It would also make it harder to tell that it is udd doing things,
> which is quite nice for us. Please consider at a minimum setting a
> custom user agent if you start using anonymous access. However,
> ideally, I'd say keep using authenticated access.
>

In the API at least, anonymous access still requires specifying the
app name. Also, there's more than one udd instance out there doing
things unrelated to udd.

jml

Revision history for this message
Max Bowsher (maxb) wrote :

> Also, there's more than one udd instance out there doing
> things unrelated to udd.

So, you're saying you want the lp:udd codebase so support using an anonymous token, so that the not-UDD binary symbols thing can use it, whilst actually-UDD remains as it currently is?

Revision history for this message
Martin Pool (mbp) wrote :

udd sets a user-agent string (or should), and obviously comes from a
particular IP address. That ought to give lp a pretty good idea who
it is.

--
Martin

Revision history for this message
Jonathan Lange (jml) wrote :

On Wed, Dec 21, 2011 at 1:44 AM, Max Bowsher <email address hidden> wrote:
>> Also, there's more than one udd instance out there doing
>> things unrelated to udd.
>
> So, you're saying you want the lp:udd codebase so support using an
> anonymous token, so that the not-UDD binary symbols thing can use it,
> whilst actually-UDD remains as it currently is?

Not really, just saying that the code in lp:udd can & is being used by
others, but they aren't using the same user as udd is. Thus the point
about tracking is specific to one particular deployment.

jml

Revision history for this message
Robert Collins (lifeless) wrote :

Well, my point is that it is better for *LP* if such things are logged
in, it lets us contact folk causing headaches. Yes, there is an 'app'
field, but that is not the same as a user id. I repeat: I would prefer
if all the instances out there running this code where logging in.

Revision history for this message
Jonathan Lange (jml) wrote :

On Wed, Dec 21, 2011 at 6:55 PM, Robert Collins
<email address hidden> wrote:
> Well, my point is that it is better for *LP* if such things are logged
> in, it lets us contact folk causing headaches. Yes, there is an 'app'
> field, but that is not the same as a user id. I repeat: I would prefer
> if all the instances out there running this code where logging in.

How is it different?

jml

Revision history for this message
Robert Collins (lifeless) wrote :

On Thu, Dec 22, 2011 at 8:15 AM, Jonathan Lange <email address hidden> wrote:
> How is it different?

Huh? You've completely lost me; they aren't the same at all..

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.