Closed Bug 818179 Opened 12 years ago Closed 6 years ago

Don't follow redirects when loading mini-manifest for a packaged app

Categories

(Core Graveyard :: DOM: Apps, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: robhudson, Unassigned)

Details

1) If the mini-manifest returns 3xx redirect, does FxOS follow it?

2) If that redirect is a 301 redirect, should we update the URL on device so update pings hit the new URL instead of the old one?

2 is a way for the developer to migrate to a new URL structure or a new domain and change where the pings go. Without this, if the developer does change the URL updates no longer work.

There are likely security concerns here. (e.g. Site A gets hacked, 301s the mini-manifest to site B)
I cannot tell what the bugs are here and what's actionable. Can you clarify?
STR:
1. Have an approved packaged app on marketplace with a few versions
2. Change the app slug from the dev hub
3. Upload another version for the app

With our current implementation of updates, changing the app slug would break updates since the mini manifest uses the slug when we ping for updates.

We are trying to fix this problem in bug 818120.

We are curious to find out if-

a) Firefox OS is inherently capable of dealing 3xx redirects in the mini-manifests 
b) Updating itself if there is a 301 (permanent redirect)
c) Security concerns (as outlined in comment 0) and how to mitigate them
Sounds like a Jonas question. Jonas - Thoughts?
Flags: needinfo?(jonas)
To keep things simple for v1, I don't think that we should follow 3xx redirects at all. Any attempt at redirects should simply not be followed.

This doesn't match the current behavior. Right now I *believe* we follow redirects, but we don't update the URL.

However I'd like to get that fixed, though that likely won't happen in time for v1.

In the meantime I'd recommend that the mozilla marketplace doesn't rely on redirects working.
Flags: needinfo?(jonas)
(In reply to Jonas Sicking (:sicking) from comment #4)
> To keep things simple for v1, I don't think that we should follow 3xx
> redirects at all. Any attempt at redirects should simply not be followed.
> 
> This doesn't match the current behavior. Right now I *believe* we follow
> redirects, but we don't update the URL.

Correct.

> However I'd like to get that fixed, though that likely won't happen in time
> for v1.

If we can find that we gott redirected in an xhr or at the channel level, this should not be too hard.
Summary: packaged apps and mini-manifests and changing URLs → Don't follow redirects in the package_path in the mini-manifest for a packaged app
Might be worth to discuss this in triage just in case after reading comment 4. I'd like to know if the risks aren't too significant if we leave this bug in (or if the opposite is true).
blocking-basecamp: --- → ?
All the discussion here is about the mini manifest, so lets scope this bug to that.

This is a nice-to-have, not a blocker.
blocking-basecamp: ? → -
Summary: Don't follow redirects in the package_path in the mini-manifest for a packaged app → Don't follow redirects when loading mini-manifest for a packaged app
Blocks: app-install
Blocks: b2g-apps-v1-next
No longer blocks: app-install
No longer blocks: b2g-apps-v1-next
Product: Core → Core Graveyard
Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.
Status: NEW → RESOLVED
blocking-basecamp: - → ---
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.