818120 - Using app_slug for the mini-manifest can break packaged app updates

Status: RESOLVED FIXED

(Marketplace Graveyard :: Consumer Pages, defect)

Description

[Rob Hudson [:robhudson]]

We allow the user to change their app slug. Since we use the app slug as part of the URL to the mini-manifest (e.g. /app/twitter/manifest.webapp) if the developer were to change their slug, the old mini-manifest URL used for updates would result in a 404.

A few possible fixes:

1. Don't allow slug changes once an app is public.

2. Use the addon ID from the database instead of the slug.

3. Bug 814131 is probably going to add the creation of a uuid and be saved to the addon.guid field and we could potentially use that.

1 has other implications and is a big change as far as developer control. 2 & 3 are ugly as far as URLs go but probably the only things that can be relied on as not changing.

Comment 1

[Andy McKay]

I use the pk in receipts for the same reason, voting for 2)

Comment 2

[Wil Clouser [:clouserw]]

I think using the UUID only in the mini-manifest URL is the "right" way to do this.  

It makes for ugly URLs...maybe we could have slugs redirect to UUIDs to ease QA?  I haven't thought through the security side of that but if the client is doing package checking it may be ok.

Comment 3

[Wil Clouser [:clouserw]]

(In reply to Andy McKay [:andym] from comment #1)
> I use the pk in receipts for the same reason, voting for 2)

If we can make receipts use UUID I'd suggest we do that.  Otherwise using PK here is fine.  End goal:  consistency.

Comment 4

[Andy McKay]

I would rather use a UUID for receipts it feels less fragile than relying on something the DB gave us. If you go for that Rob, I'll alter receipts to match.

Comment 5

[Rob Hudson [:robhudson]]

https://github.com/mozilla/zamboni/commit/a1bb5a7