Jason Smith [:jsmith] Reporter
	Description • 12 years ago

Build:

Device - Unagi
Build Type: Beta 12/11/2012
Identity prefed on with debugging

Steps:

1. Go to https://marketplace.firefox.com/app/notes in the browser
2. Select login
3. Select to type your email - type in an existing account for your "Firefox account" and hit enter
4. Type in a password for that account and hit enter

Expected:

Login through trusted UI should be successful, allowing me (the admin) to access the reviewer only page.

Actual:

The persona dialog in the trusted UI successfully disappears, but login fails to complete.

Error Console of Interest:

12-11 19:20:57.003: E/GeckoConsole(677): [JavaScript Error: "redeclaration of const kIdentityDelegateWatch" {file: "chrome://browser/content/identity.js" line: 36}]

Full logcat attached.

	Jed Parsons (use needinfo, please) [:jedp, :jparsons]
	Comment 1 • 12 years ago

Thanks for the detailed report, Jason, and the STR.

The redeclaration of kIdentityDelegateWatch is ignorable.

I think the issue here is that marketplace does not use the b2g persona site we're using on b2g/gaia, namely notoriousb2g.personatest.org.  (Check the page source of marketplace.firefox.com - they are importing from persona.org.)  So we have a cross-domain problem.

Currently, I believe only marketplace-dev is using our current server, notoriousb2g.

	Jason Smith [:jsmith] Reporter
	Comment 2 • 12 years ago

It actually didn't work on marketplace-dev either, actually.

How are we making sure btw that any site that say using persona against persona.org then still works on the b2g device? 

I mean a lot legacy sites I'm not expecting to point to notoriousb2g.personatest.org, right?

	Jason Smith [:jsmith] Reporter
	Comment 3 • 12 years ago

Hmm...okay. I see a potential big problem here in this situation then:

Let's take a different app that I know happens to be a tier 1 - the times crossword - http://crossword.thetimes.co.uk/. They happen to include persona using the following code snippet:

<script src="https://browserid.org/include.js" type="text/javascript"></script>

Now I understand that's the only include.js to point to that redirects to:

https://login.persona.org/include.js

Right now, I cannot complete a login into that times crossword app for the same reasons that I hit with the marketplace server. However, a few things don't align in my mind right now. Here's what my brain is thinking:

1. We can't regress existing sites using persona
2. We can't provoke sites to use user agent sniffing to determine which include.js to use based on the platform (say b2g vs. desktop, for example)
3. Your typical average site isn't going to include the b2g-specific include.js if they use persona

What I think should be happening here is that we should be satisfying the typical use case that a developer decides to use the typical login.persona.js. If we don't, we'll end up in this situation that we just hit - resulting in many sites being unable to use persona unless they move over to this b2g-specific implementation. We simply cannot break tier 1 app experience or generally, the typical use case for how a developer includes the include.js for persona.

Somebody needs to enlighten me on why my brain is seeing the current situation as a bunch of pieces that don't just add up. It's almost like the current persona implementation for b2g would allow anyone uses the b2g include.js to work, but all others to fail. But in reality, that would be regressing the existing persona experience with the pref off with many of these sites actually working.

	Ben Adida [:benadida]
	Comment 4 • 12 years ago

Jason,

High-level: we designed our implementation plan exactly this way, knowing there would be temporary breakage. The reason is that we could not implement the unverified email feature in the core Persona service in time for the client-side code deadlines.

Of course, we intend for all the things you mention to work: Marketplace and other relying parties, working on all browsers with the same code.

Here's our rough plan, which Jed and I will expand on soon:

* b2g will run at a well-defined hostname, e.g. fxos-persona.org

* marketplace should, when delivering code to FXOS, use the b2g-specific include and the b2g-specific verifier.

* other sites will be broken for a little bit longer.

* as soon as we can merge the functionality into the core Persona service, we will make sure the fxos-persona.org hostname points to the core Persona service.

* in the meantime, this means Persona in other RPs may break.

* even if we have to run a separate Persona service for B2G (which is a possibility), we will share the signing keys so that assertions are valid against either verifier.

So, what this means for now is that we should ensure Marketplace is working with a hostname for the include and verifier TBD by Jed. We will have to tolerate some brokenness from other Persona-using apps for a little while longer.

	Kumar McMillan [:kumar]
	Comment 5 • 12 years ago

To clarify, we are using notoriousb2g.personatest.org for Marketplace and everything is working great on B2G. We have only deployed this to our altdev instance -- https://marketplace-altdev.allizom.org/ -- because we do not want to interrupt general QA which happens on our dev instance.

	Bill Walker [:bwalker] [@wfwalker]
	Comment 6 • 12 years ago

(In reply to Ben Adida [:benadida] from comment #4)
> 
> * marketplace should, when delivering code to FXOS, use the b2g-specific
> include and the b2g-specific verifier.
> 

Ben, please make sure the marketplace team is aware of what needs to be done.

	Jason Smith [:jsmith] Reporter
	Comment 7 • 12 years ago

(In reply to Bill Walker [:bwalker] [@wfwalker] from comment #6)
> (In reply to Ben Adida [:benadida] from comment #4)
> > 
> > * marketplace should, when delivering code to FXOS, use the b2g-specific
> > include and the b2g-specific verifier.
> > 
> 
> Ben, please make sure the marketplace team is aware of what needs to be done.

Just started a thread on this actually. Adding you now.

	Jason Smith [:jsmith] Reporter
	Comment 8 • 12 years ago

Talking with others on the thread and the bug, this is actively being looked into in the development process. Don't think we need to track this explicitly, however, in bugzilla, given that this is a server-side issue that appears to already be tracked.

I'll close this as invalid and leave tracking to whatever happening in the BID github.