Bugzilla

Reporter

Updated

•

5 years ago

Type: defect → task

Reporter

Updated

•

5 years ago

Flags: needinfo?(jrgm)

Flags: needinfo?(jbuckley)

Comment 1

•

5 years ago

Is there a particular time this needs to be changed at? Say in coordination with a blog post or release? I've put it in my calendar, I'll do the change.

Sandy Sage

Comment 2

•

5 years ago

Marketing promotion happens at 6am PT. Would it make sense to plan to do it an hour before or even earlier?

Comment 3

•

5 years ago

Up to you, but it's an instant change that I can make at 6am PT

Flags: needinfo?(jrgm)

Flags: needinfo?(jbuckley)

Comment 4

•

5 years ago

I just realized that the redirect URIs will also need to change. /me facepalms self

The new website is already live (reusing the same content and content delivery mechanism as the original "lockbox"), and the original links will work for some time, but not forever.

Can a given client_id have multiple redirect URIs registered? If so, then I can update with the expected URIs (which change the domain from lockbox.firefox.com to lockwise.firefox.com). If not, we'll have to figure something out ...

Flags: needinfo?(stomlinson)

Ryan Kelly [:rfkelly]

Comment 5

•

5 years ago

Can a given client_id have multiple redirect URIs registered?

Not currently, although I can think of a couple of times when this would have been useful in the past. It may be that the simplest "figure something out" option is actually to add support for multiple redirect URIs on the FxA side.

What prevents us from pre-emptively using the new redirect_uri, is it just that the new branding would go live prematurely?

Comment 6

•

5 years ago

•

Edited

(In reply to Ryan Kelly [:rfkelly] from comment #5)

Can a given client_id have multiple redirect URIs registered?

Not currently, although I can think of a couple of times when this would have been useful in the past. It may be that the simplest "figure something out" option is actually to add support for multiple redirect URIs on the FxA side.

I suspect this is might be the only viable option \-:

What prevents us from pre-emptively using the new redirect_uri, is it just that the new branding would go live prematurely?

Nothing prevents supporting both old and new redirect URIs "now". We're not concerned with these URLs leaking, since they are not user visible unless something goes horribly wrong. You can go to https://lockwise.firefox.com right now and get content (-:

The concern is supporting only one redirect URI. If the server updates for the new URI before the clients, all the old clients will be unable to sign in; if the client updates before the server, the new clients will be unable to sign in.

Ryan Kelly [:rfkelly]

Comment 7

•

5 years ago

Hrm, right, this is basically the same shape as rotating a signing key or a client_secret - both cases for which we allow multiple active values in order to enable a seamless transition.

The other option would be to just make a completely new OAuth client_id for Lockwise and retire the old Lockbox one once enough clients have been updated. I don't know how much this would mess things up in metrics or reporting or what-not.

Comment 8

•

5 years ago

A change in client_id throws off the telemetry, so is very undesirable.

I'll note that updating the URI is not urgent or time-critical. The original domain will be left open for some time. If we have an issue for tracking the desired resolution, we can have decommissioning it blocked by it.

Ref https://github.com/mozilla/fxa/issues/1045

Reporter

Comment 9

•

5 years ago

Flags: needinfo?(stomlinson)

Reporter

Comment 10

•

5 years ago

:m_and_m - With Trailhead we are a bit over our heads and I'm trying to punt on anything not needed right now, I opened [1] to allow multiple redirectUri's per client. I imagine we can get to it early in Q3, I don't think it's much effort, it's just trying to find the time to make sure we've done all the necessary due diligence.

[1] - https://github.com/mozilla/fxa/issues/1045

Comment 11

•

5 years ago

MySQL [fxa_oauth]> update clients set name = 'Firefox Lockwise' where id in (0x1b024772203a0849, 0x98adfa37698f255b, 0xe7ce535d93522896);
Query OK, 3 rows affected (0.01 sec)
Rows matched: 3 Changed: 3 Warnings: 0

Here's the current redirect_uri's:

+------------------+------------------+--------------------------------------------------------------------------+
| name             | hex(id)          | redirectUri                                                              |
+------------------+------------------+--------------------------------------------------------------------------+
| Firefox Lockwise | 1B024772203A0849 | https://2aa95473a5115d5f3deb36bb6875cf76f05e4c4d.extensions.allizom.org/ |
| Firefox Lockwise | 98ADFA37698F255B | https://lockbox.firefox.com/fxa/ios-redirect.html                        |
| Firefox Lockwise | E7CE535D93522896 | https://lockbox.firefox.com/fxa/android-redirect.html                    |
+------------------+------------------+--------------------------------------------------------------------------+

Let me know what the new redirect uri's should be

Flags: needinfo?(linuxwolf)

Comment 12

•

5 years ago

(In reply to Jon Buckley [:jbuck] from comment #11)

Let me know what the new redirect uri's should be

There are bigger questions/concerns that need addressing before we can change these, since changing them will break for some large percentage of our users. Will follow up with FxA engineering, though I think we're good for now.

Thanks Jon!

Flags: needinfo?(linuxwolf)

Vlad Filippov (:vladikoff)

Updated

•

5 years ago

Status: NEW → RESOLVED

Closed: 5 years ago

Resolution: --- → FIXED

Comment 13

•

5 years ago

I see the GitHub org already changed the address.

Sadly the way it works is https://lockbox.firefox.com/fxa/ios-redirect.html?jbuck=true now redirects to https://lockwise.firefox.com/fxa/ios-redirect.html with no query params. This broke OAuth flows in app-services code. What should we do?