If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Investigate cookie passing on app update

RESOLVED FIXED in 2013-09-10

Status

Marketplace
General
P1
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: basta, Assigned: cvan)

Tracking

Avenir
2013-09-10
x86_64
Windows 7
Points:
---

Details

(Reporter)

Description

4 years ago
Investigate whether the https://marketplace.firefox.com cookie is passed to app minifest URLs on update.

This might be most easily observed with a carefully crafted stackato app (obviously not using the m.f.c origin).
(Assignee)

Updated

4 years ago
Assignee: nobody → cvan
Target Milestone: --- → 2013-08-27
(Assignee)

Updated

4 years ago
Target Milestone: 2013-08-27 → 2013-09-03
Priority: -- → P1
(Assignee)

Comment 1

4 years ago
The answer is no :(

Reproduced on Firefox OS Keon Geeksphone and Firefox OS Simulator.

1) Load http://cookiemonsta.paas.allizom.org/ from the browser on your phone.
2) Click the "Install" button.
3) Launch "Cookie App" from your homescreen.
4) Notice that `document.cookie` is empty - http://cl.ly/image/1u0U0d450B1d/Screen%20Shot%202013-09-03%20at%209.49.59%20PM.png
5) Exit the packaged app and load the browser.
6) Load http://cookiemonsta.paas.allizom.org/inspector
7) Notice that `document.cookie` is `pro=4004ee.33` - http://cl.ly/image/2X0v3C0W303u/Screen%20Shot%202013-09-03%20at%209.49.30%20PM.png (This means that the act of installing the packaged app from the browser actually did set a cookie for the domain.)

Expected behaviour:
Because we install the packaged app http://cookiemonsta.paas.allizom.org/minifest?pro=4004ee.33 which sets a cookie of `pro=4004ee.33` that should get passed to the packaged app.

Actual behaviour:
Any cookies set by the server from which the packaged app was installed do not get passed to the packaged app.

It's worth noting that setting the origin in the manifest makes no difference:

    {
        ...
        "origin": "app://cookiemonsta.paas.allizom.org"
    }

Next steps:

1) Make sure we're doing the right thing. Spotcheck, Basta? (Then, spotcheck, Fabrice?)
2) Ask Gaia team (fabrice, bsmith) for patch/workaround.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: 2013-09-03 → 2013-09-10
(Assignee)

Comment 2

4 years ago
Code lives here BTW: https://github.com/cvan/cookiemonsta
(Reporter)

Comment 3

4 years ago
I think you missed a chunk of that.

You need to do your steps (1-7), then test that when your app hits the minifest for an update, the minifest gets the cookie passed to it in the Cookie header. So:

8) Visit the settings app and force an update
9) Look at the server logs and see that the cookie pro=4004ee.33 gets passed to the minifest URL.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 4

4 years ago
I did this, and saw no evidence that this happens.

Basta, I'll let you take a stab at this.
(Assignee)

Comment 5

4 years ago
Jonas, I wanted to confirm with you that this (comment 1) is how the webapps cookie passing is supposed to work in Firefox OS. Thanks for your help!
(Assignee)

Comment 6

4 years ago
Investigation completed. The thing we thought would work doesn't seem to actually work.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Can you please file a bug on this as what is described in comment #0 *should* work.

I.e. from the marketplace app's point of view, cookies should work as normal. A cookie created inside of the app should be used when the device pings for update.

Normal cross-domain and secure-only rules apply though of course.
You need to log in before you can comment on or make changes to this bug.