Closed Bug 796198 Opened 9 years ago Closed 8 years ago

Use the right cookie jar when downloading package and minimanifest for packaged apps

Categories

(Core Graveyard :: DOM: Apps, defect, P1)

x86
macOS
defect

Tracking

(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)

RESOLVED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp +
Tracking Status
firefox19 --- fixed
firefox20 --- fixed
b2g18 --- fixed

People

(Reporter: sicking, Assigned: fabrice)

References

Details

(Whiteboard: [qa-])

Attachments

(2 files)

When downloading the mini manifest as well as the app package we should use the same cookie jar as was used to load the page which called apps.install/installPackage.

This means that we for all packaged apps have to remember which cookie jar was used at the time of the install call and then make sure to use the same cookie jar during both the initial download as well as during updates.
I don't think we need any additional necko support for this. "All" we need to do is to create a custom nsILoadContext and hook up to the channels used for the mini manifest and the package.
Nominating for blocking as I my understanding is that the marketplace needs this in order to restrict access to non-reviewed packaged apps such that only reviewers can install them.
blocking-basecamp: --- → ?
We currently download the manifests from the content process, and I think it would be easier to implement that cookie jar if we move all the network access in the parent since this is where we have direct access to all the meta-data associated with apps.
Indeed, we'd have to do that since we're planning on adding security checks in the necko code which prevents apps from using each other's cookie jars.
blocking-basecamp: ? → +
Blocks: market-packaged-apps
No longer blocks: 795181
Priority: -- → P3
I know you're at TPAC, Jonas, but can you provide a status update when you get home?  Should we give this to someone else?
Flags: needinfo?(jonas)
This bug has been called out as likely having risk to non-B2G platforms. Given that, marking as P1, and moving into the C2 milestone. We should prioritize this landing to mozilla-beta as soon as possible, to prevent late-breaking regressions to other platforms.
Priority: P3 → P1
Target Milestone: --- → B2G C2 (20nov-10dec)
Not marketplace related - removing from tracking bug.
No longer blocks: market-packaged-apps
Blocks: 814236
Jonas, there's been no update from you since October. What needs to happen in this bug?
What is the status of this bug?
stealing from Jonas since he has no time to work on this.
Assignee: jonas → fabrice
Flags: needinfo?(jonas)
No longer blocks: app-install
This patch is just doing some preliminary set up, moving all the network accessing code into the parent.
Attachment #689941 - Flags: review?(jonas)
In this part we save the installer appId and isBrowser flag, and reuse it on all the network channels except appcache downloads.

Unfortunately I could not really test it since the reviewer tools  from the marketplace app redirect into the browser.
Attachment #689943 - Flags: review?(jonas)
Attachment #689941 - Flags: review?(jonas) → review+
Comment on attachment 689943 [details] [diff] [review]
part 2 : set the cookie jars

Review of attachment 689943 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with that fixed.

::: dom/apps/src/Webapps.jsm
@@ +1209,5 @@
>    },
>  
> +  // Creates a nsILoadContext object with a given appId and isBrowser flag.
> +  createLoadContext: function createLoadContext(aAppId, aIsBrowser) {
> +    return LoadContextCallback.prototype = {

This looks weird. Why are you setting LoadContextCallback.prototype rather than simply returning the new object?
Attachment #689943 - Flags: review?(jonas) → review+
Whiteboard: [qa-]
Whiteboard: [qa-][status-b2g18:fixed] → [qa-]
No longer blocks: packaged-apps
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.