SCA-user is rejected by LP API as unauthorized

Thanks for your bugreport.

Can you please attach the purchase log file from:
 ~/.cache/software-center/software-center.log

thanks,
 Michael

Are you behind a webproxy or a firewall or is there anything else usualy about your network setup?

Hello.
I have no proxies, but I am behind a a router and a firewall. Its a simple home network. I can do some experiments if you want.

Thanks a lot for the log! Unfortunately there is nothing that looks unusual in there :/

Do you have more files in their, like ~/.cache/software-center/software-center.log.1 or .0 ?

On the server it looks like you got added correctly. Does installing/removing software with software-center works for "normal" items?

What happens if you go to the file menu and click on "reinstall previous purchase" ?

There are no more log files in ~/.cache/software-center/.
I have no problems with "normal" items :)
If I click on "reinstall previous purchase", after authentication, there are no items available.

Thanks a lot cuby for this info. I'm debugging this with someone from the server team now to see what might cause this issue.

The 'Unauthorized' message is being caused when the privileged 'software-center-agent' Launchpad user that we use on the server tries to call getArchiveSubscriptionURL() via the Launchpad API. It is being rejected as unauthorized by the Launchpad API, even though the same authentication has just been used to create the subscription: (from softwarecenteragent/utilities.py)

{{{
            # This can raise HTTPError 400 - ArchiveNotPrivate,
            # AlreadySubscribed,
            subscription = p3a.newSubscription(subscriber=subscriber)

            # This can rais HTTPError 401 if not logged in as sca.
            token = subscriber.getArchiveSubscriptionURL(archive=p3a)
}}}

Details of the irc discussion are at:
https://pastebin.canonical.com/39101/

This was also discussed during a weekly call, and flacoste said that he's seen this before with the LP API, and that we could try the call multiple times (although from the above irc conversation, Anthony mentioned that the logs show this error over a period of time).

The sca logs for this error actually included an oops report, Oops-1756EA1582
Looking at that it seems we're failing to access the 'latitude' attribute on Jane's PersonLocation, when trying to take a snapshot of the person:

  Unauthorized: (<PersonLocation at 0x2b480af0c4d0>, 'latitude', 'launchpad.View')

    Traceback (most recent call last):
  Module zope.publisher.publish, line 134, in publish
    result = publication.callObject(request, obj)
  Module lazr.restful.publisher, line 171, in callObject
    WebServicePublicationMixin, self).callObject(request, object)
  Module canonical.launchpad.webapp.publication, line 483, in callObject
    return mapply(ob, request.getPositionalArguments(), request)
  Module zope.publisher.publish, line 109, in mapply
    return debug_call(obj, args)
   - __traceback_info__: <security proxied lazr.restful._resource.EntryResource instance at 0x2b4807f64190>
  Module zope.publisher.publish, line 115, in debug_call
    return obj(*args)
  Module lazr.restful._resource, line 913, in __call__
    result = self.do_POST()
  Module lazr.restful._resource, line 746, in do_POST
    return self.handleCustomPOST(operation_name)
  Module lazr.restful._resource, line 1325, in handleCustomPOST
    value = super(EntryResource, self).handleCustomPOST(operation_name)
  Module lazr.restful._resource, line 730, in handleCustomPOST
    return operation()
  Module lazr.restful._operation, line 81, in __call__
    self.context, providing=providedBy(self.context))
  Module lazr.lifecycle.snapshot, line 85, in __init__
    value = getattr(ob, name, _marker)
  Module lp.registry.model.person, line 612, in latitude
    return ProxyFactory(self.location).latitude
Unauthorized: (<PersonLocation at 0x2b480af0c4d0>, 'latitude', 'launchpad.View')

This would seem to say that it will fail consistently for users like Jane that have opted to hide their location, until we sort this out on LP. We'll discuss ways to work this out with them.

Why does the process need to access a users location? That data is so private that not even a Launchpad Admin can see it. I suppose it does not care, but the change operation thinks it has changed.

I proposed we annotate the interface with doNotSnapshot() to ensure it is not used. Since only the real user can see and access the information, such changes never need to be snapshotted to communicate the change.

Fixed in stable r11845 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11845>.

We've done a nodowntime deployment, but I don't know if the necessary machines to deploy this fix are in the nodowntime set (because I don't know what machines are necessary in deploying the fix).

I believe no further changes are needed on this but I'll add it to our backlog so it gets a bit of end-to-end QA

Unable to test due to the inability to deactivate locations on Launchpad, I will test what I can of this.

On Tue, Jan 25, 2011 at 2:06 AM, Dave Morley <email address hidden> wrote:
> Unable to test due to the inability to deactivate locations on
> Launchpad,  I will test what I can of this.

What do you mean here?

Launchpad seems to still have an idea in its database of your lat/long, but it does not expose any ui in /+me to edit it, afaics.

Location lat/long is not longer used by Lp. It was only used by maps and that feature was removed. Everyone's locate is effectively disabled. This issue was about improper access to the location object after Location was set to hidden. This could be tested by a number of people who have hidden locations such as barry. We know for certain that the problem fields are not snapshotted by any Lp code now.

Payment goes through on Staging.