Update of unpurchased and sideloaded apps causes U1 account invalidation

[Jean-Baptiste Lallement]

current build number: 170
device name: arale
channel: ubuntu-touch/rc-proposed/meizu.en

I had Cut The Rope Full installed for testing directly from the click package and which cannot be upgraded. If I apply all the updates available, including CTR, the Ubuntu One account is removed.

Expected Results:
CTR is not upgraded, but the account is preserved.

There is following message in system-settings log file:
2015-11-17 07:44:19,313 - WARNING - START: com.zeptolab.cuttherope.full
2015-11-17 07:44:19,322 - WARNING - void UpdatePlugin::Network::getClickToken(UpdatePlugin::Update*, const QString&)
2015-11-17 07:44:19,916 - WARNING - HTTP Status: 401
2015-11-17 07:44:19,916 - WARNING - Emitting credetials error.
2015-11-17 07:44:19,997 - WARNING - Reply is not valid.
2015-11-17 07:45:20,038 - WARNING - QObject::startTimer: Timers cannot be started from another thread
2015-11-17 07:51:10,021 - WARNING - UbuntuClipboard - Got invalid serialized mime data. Ignoring it.
2015-11-17 07:51:11,143 - WARNING - PAUSE: com.zeptolab.cuttherope.full

[Alberto Mardegan (mardy)]

Reassigning, as u-s-s-o-a is not involved in the account's removal.

[Victor gonzalez (victor-gonzalez-0)]

I reproduced the bug when trying to install Sudoku app from store, not when upgrading:

1. Tap on install button
2. Logging error
3. I headed to accounts and U1 account was removed.

Attached syslog+log/upstart, if you need different logs please let me know.

Time stamp: 9-9:05_13/05

[Victor gonzalez (victor-gonzalez-0)]

Another user from BQ forums had the same behaviour with sudoku too.

[David Barth (dbarth)]

We have a fix for that ready in a silo. Thanks for the feedback on the importance of the issue.

[dobey (dobey)]

There is no fix for this specific bug in any silo. The issue in this bug is that when a paid app is side loaded onto the device, but has never been purchased by the account in use on the phone, the server returns a 401 during the attempt to upgrade.

Victor, your issues in comment #2 and comment #3 seem to be a different problem, albeit with similar symptoms.

There are no fixes in queue to prevent requiring logging in again in these situations, so far. The "fix" which David refers to, will happen over multiple silos, and should improve the UX in these situations some, but does not remove the need to log in again when they occur.

I'm going to move this bug over to the server, as it really shouldn't return a 401 in this specific case, but probably a 404 instead, which should then just result in such updates being skipped rather than falsely causing the invalidation of the token.

[dobey (dobey)]

I'm moving this bug to CPI, because it returns a 401 when we perform the HEAD request to fetch the X-Click-Token for downloading the package. This is because an older version of the package in question was side-loaded onto the phone, but the app was not purchased for the account being used. Instead of a 401 (since the URL was signed with a valid token), it would be better if the server returned a 404 perhaps, so that the update would just be skipped. This would prevent the client from thinking the credentials are invalid (because 401 or 403 implies the authorization is not valid), and avoid causing the token to be deleted on the phone.

[dobey (dobey)]

It seems like an appropriate solution to this would be for the updates API endpoint to only return updates for things which the server has record of the user installing. The /purchases/ endpoint on SCA to show subscriptions does indicate that free apps are also listed in that subscriptions list, so only "Complete" subscriptions being returned in the available updates list, would certainly prevent this specific issue.

[Pat McGowan (pat-mcgowan)]

@bret can you take a look

[Bret Barker (noise)]

The server should return a 403 (forbidden) in that case because the given credentials are not allowed for that package.

However, I don't think we need to go out of our way to support sideloading paid apps onto a device with another user account - essentially giving away a copy of the app.

[dobey (dobey)]

@Bret OK on 403, but AFAICT a 401 is currently being returned.

How is having the server only give available updates in the JSON for apps which the user has actually installed from the store, going out of our way to support sideloading paid apps onto a device with another account? We don't currently support that, and neither would a fix to prevent this specific issue from happening support it (nor would it not support it, really).

[Bret Barker (noise)]

Right, I meant the store _should_ return a 403 in that case. However, I think there's some complicated interactions of the store services that make that distinction difficult in this case.

Meanwhile, shouldn't the client just not even ask the store for updates to side-loaded apps?

[dobey (dobey)]

There is no way for the client side to know what a "sideloaded" app is. We could theoretically hit the server, grab the user's list of "purchases" every time, and then compare that, but then that would be a lot more data getting transferred, along with battery being used. So, no, we can't really do that in the updates panel.

[Pat McGowan (pat-mcgowan)]

AIUI from the recently duped bug this can also happen when a free app is installed from the store then later becomes a paid app.