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

NEW
Unassigned

Status

Core Graveyard
DOM: Apps
5 years ago
2 months ago

People

(Reporter: robhudson, Unassigned)

Tracking

unspecified

Firefox Tracking Flags

(blocking-basecamp:-)

Details

(Reporter)

Description

5 years ago
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?

Comment 2

5 years ago
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.

Updated

5 years ago
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

Updated

5 years ago
Blocks: 802574

Updated

5 years ago
Blocks: 863032
No longer blocks: 802574

Updated

5 years ago
No longer blocks: 863032

Updated

2 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.