Closed Bug 939270 Opened 11 years ago Closed 10 years ago

User is prompted to sign in twice while making a purchase on Firefox Mobile

Categories

(Marketplace Graveyard :: Payments/Refunds, defect, P3)

All
Android
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 939328

People

(Reporter: krupa.mozbugs, Assigned: kumar)

References

Details

Attachments

(1 file)

Attached video video
Nightly 28.0a1 (2013-11-14)

steps to reproduce:
1. Load marketplace.allizom.org on stage
2. Make sure you are not logged in
3. Search for :paid apps
4. Click the Buy button for one of the listed premium apps
5. When prompted to sign to persona, use an unverified email address
6. Create and confirm password; press continue


expected behavior:
Webpay screen to enter PIN loads

observed behavior:
Webpay screen loads with the Sign in button. Upon signing in again, the webpay screen for PIN entry loads.

Looks like upon the first log in, user is only signed into marketplace and needs to separately log in to webpay again.

I made an edgy video showing this behavior. Don't watch if you have motion-sickness.
Assignee: nobody → kumar.mcmillan
Priority: -- → P1
Target Milestone: --- → 2013-12-03
Hi Wes,
We are unable to create a single sign-on login for Marketplace because the nav.mozPay() window on Android does not have access to the same cookies that Firefox Mobile has access to (for the same domain). I realize you probably did that to mimic B2G mozPay but is there any reason why we shouldn't give it access to cookies?

Krupa, there is no way to fix this given the current state of the platform. Well, maybe we could think of a hack. 

btw, why is this a P1? Does it really need to block?
Target Milestone: 2013-12-03 → ---
oh, my bad, I made it a P1 late on Friday when I hastily read the description :)
Priority: P1 → --
FF on Android currently runs each app in its own profile, so that we appear like separate native Apps to Android. Each profile has its own cookies/passwords/etc.

We've batted around removing this, but nothing in the plans right now.
Yes, but, the mozpay payment window isn't an app per se. What I'm doing is using Firefox Nightly where code on a page calls nav.mozPay(). That opens a window but the window can't access any of the cookies that Nightly has. In other words, it doesn't function like a new tab and that's causing this bug. It might be a wontfix bug, I don't know what we want to do here.
Mark, can you help us decide what the Android implementation of mozPay should do here?

Currently mozPay opens a new window that looks like window.open() but does not behave the same. Specifically, it does not share same-domain cookies with the rest of the browser (or app).

It would be nice if the mozPay window could share same-domain cookies because we can access our user login session.

Let me know if you need more info or more context.
Flags: needinfo?(mark.finkle)
Priority: -- → P3
More context is needed, I think:
* Is this just from Firefox (the browser) or are you using mozPay from a webapp?
* If this is from Firefox and the mozPay window is just opening as a new tab in the browser, I assume same-domain would "just work". Under what situation would that not work?
Flags: needinfo?(mark.finkle)
(In reply to Mark Finkle (:mfinkle) from comment #6)
> More context is needed, I think:
> * Is this just from Firefox (the browser) or are you using mozPay from a
> webapp?
> * If this is from Firefox and the mozPay window is just opening as a new tab
> in the browser, I assume same-domain would "just work". Under what situation
> would that not work?

The bug was filed for behavior on the browser.
(In reply to Mark Finkle (:mfinkle) from comment #6)
> More context is needed, I think:
> * Is this just from Firefox (the browser) or are you using mozPay from a
> webapp?

mozPay() should work in either case. The most traveled path will be mozPay() called from the browser (example: purchasing an app from the Marketplace). In the case of calling mozPay() from an app, it will be for in-app payments.

> * If this is from Firefox and the mozPay window is just opening as a new tab
> in the browser, I assume same-domain would "just work". Under what situation
> would that not work?

Currently it is not working. A simple test to reproduce would be this:

- make a webpage at foo.com that sets/reads a cookie
- hook up a payment provider to Android whose payment start page is on foo.com (here's how to configure a custom pay provider https://github.com/wesj/devMarketplace)
- call mozPay() from the browser
- within the foo.com *payment start page* inside the mozPay() window, try to read the cookie that was set by foo.com

From what I see in our session cookie behavior the above scenario would fail but it should not. This seems like a bug to me.
(In reply to Kumar McMillan [:kumar] from comment #8)

> From what I see in our session cookie behavior the above scenario would fail
> but it should not. This seems like a bug to me.

Another question we should figure out: Does the session cookie behavior fail for non-mozPay() scenarios? If a tab at foo.com sets a cookie and opens another tab, can the second tab access the cookie? That should be the same situation as mozPay, right?
(In reply to Mark Finkle (:mfinkle) from comment #9) 
> If a tab at foo.com sets a cookie and opens
> another tab, can the second tab access the cookie? That should be the same
> situation as mozPay, right?

It should be the same situation, yes. Well, I'd like it to be :) It seems like the right thing to do because mozPay() just opens a new window, that's all.
(In reply to Mark Finkle (:mfinkle) from comment #9)
> Another question we should figure out: Does the session cookie behavior fail
> for non-mozPay() scenarios? If a tab at foo.com sets a cookie and opens
> another tab, can the second tab access the cookie? That should be the same
> situation as mozPay, right?

FYI :andym did a cookie test independent of Webpay within mozPay and cookies were working fine on Android.

This looks like a problem with either the Webpay site or Persona. We'll deduce further.
Version: 1.4 → 1.5
See Also: → 939328
Hmm, not sure why we never duped this to bug 939328 :/ They are identical
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: