Uses authenticated access to Launchpad when anonymous will do

[Jonathan Lange]

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.

[Robert Collins (lifeless)]

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.

[Jonathan Lange (jml)]

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

[Max Bowsher (maxb)]

> 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?

[Martin Pool (mbp)]

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

[Jonathan Lange (jml)]

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

[Robert Collins (lifeless)]

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.

[Jonathan Lange (jml)]

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

[Robert Collins (lifeless)]

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..