Closed Bug 1182255 Opened 9 years ago Closed 9 years ago

Only allow /signin (not /signup) in Firefox for iOS

Categories

(Firefox for iOS :: Firefox Accounts, defect)

Product:
Firefox for iOS
Component:
Firefox Accounts
Platform:
Other
iOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
fxios + ---

People

(Reporter: nalexander, Assigned: rfkelly)

References

(
URL
)

Details

It's possible that the Sync state machine for Firefox for iOS won't implement "clean server" initialization, at least for v1.  Such initialization is tricky and error-prone; we didn't implement it for the first few Fennec releases.

To work-around, we might restrict Firefox for iOS to only allow /signin (not /signup) on the content server.  The idea is that if you already have a Firefox Account, then you likely already have a Desktop (or Android) Sync client, which will have initialized the server.  This isn't perfect, since the server can be wiped, or you can be node-migrated, etc -- but it's a decent work-around.

This ticket tracks:

* having fxa-content-server folks estimate the work to not show /signup;
* whatever Firefox for iOS work is needed to opt-in to this configuration.
stomlinson: can you estimate the amount of work that this is for the fxa-content-server team?  And how Firefox for iOS would signal that it doesn't want to allow account creation?  Thanks!
Flags: needinfo?(stomlinson)
Triage note: we should keep this ? along with a few other decisions that Karen and I are keeping in our heads.
tracking-fxios: --- → ?
Hey Nick,
Can you give us a bit more context? Vlad and I are shooting various speculations back and forth, but figure we should just ask.

What constraints &| problems are you facing?

It sounds like v1 of Fx on iOS is unable to poll the auth server to find out when the user has verified their email.

If this is the case, we may have to disable password reset as well, because that would have the same problem.
Flags: needinfo?(stomlinson) → needinfo?(nalexander)
(In reply to Shane Tomlinson [:stomlinson] from comment #3)
> Hey Nick,
> Can you give us a bit more context? Vlad and I are shooting various
> speculations back and forth, but figure we should just ask.

Yes.

> What constraints &| problems are you facing?

The Sync state machine that configures a blank server is complicated.  Very complicated.  This is what needs to happen when you have a brand new account, an existing account that got Sync-node migrated (now rare, but common in the past), or a wiped server (which is a Sync client's get out of jail card).

That is, you arrive at a Sync endpoint that doesn't have meta/global or crypto/keys.  You're the first to the party.

> It sounds like v1 of Fx on iOS is unable to poll the auth server to find out
> when the user has verified their email.

No, nothing like this.  It means you have auth and everything set up, but you have a blank Sync endpoint.  You make progress by doing a bunch of finicky things that we're not going to implement for v1.

> If this is the case, we may have to disable password reset as well, because
> that would have the same problem.

Password reset will not be smooth if the iOS device is the first to the new Sync endpoint.  Password reset looks like Sync-node migration.
Flags: needinfo?(nalexander)
Assignee: nobody → stomlinson
What will happen if, despite our efforts, the iOS device finds itself trying to sync against an empty sync endpoint?  Will it silently fail?  Error out?  Wipe all the user's local bookmarks? :-)

As you note, this is going to happen some non-zero percetnage of the time anyway due to node migrations, password resets, etc.  How bad the outcome is will affect how much work we can put into trying to prevent it.

Perhaps it's wishful thinking, but I wonder if we can't finesse this away from within FxiOS by pretending that it's not an unexpected error state, but rather a partial success state.  If you try to read /meta/global and it's not there, message the user to say "Almost there!  Now connect a Desktop Firefox to sync your bookmarks, history, and more".
(In reply to Ryan Kelly [:rfkelly] from comment #5)
> What will happen if, despite our efforts, the iOS device finds itself trying
> to sync against an empty sync endpoint?  Will it silently fail?  Error out? 
> Wipe all the user's local bookmarks? :-)

Log and abort. The current behavior is relatively safe, assuming no node reassignments (which we haven't tested).

The main thing I'm hoping to avoid: a user trying to sync their iPad with their iPhone, or trying to back up data from their iPhone without first connecting to a desktop. Nothing will happen, and they'll be disappointed.

This is a mitigation, a behavior limiter, which I primarily intend as a hedge. I'd like to have the state machine complete by Christmas.


> If you try to read /meta/global and it's
> not there, message the user to say "Almost there!  Now connect a Desktop
> Firefox to sync your bookmarks, history, and more".

On first sync that might be a good idea. I'm a little worried about iOS lifecycle stuff, but we might be able to make this happen.
> Perhaps it's wishful thinking, but I wonder if we can't finesse this away from within FxiOS

Naturally, a big part of this is me selfishly wanting to use the FxiOS release to drive as many new account creations as possible...
We'd definitely like to; v1s are always embarrassing. We hope to get 1.1 and 2.0 out the door this year, which will be the releases that we promote and should drive growth.
Ryan, Shane: can I get a status update on this?

If it's not something we can get done and deployed within the next few weeks, we'd love to know ASAP so we can try to get the full state machine built or prepare for non-technical mitigations.

Thanks!
tracking-fxios: ? → +
Flags: needinfo?(stomlinson)
Flags: needinfo?(rfkelly)
:rnewman, can you give us concrete dates?
Flags: needinfo?(stomlinson)
Context: https://wiki.mozilla.org/Mobile/Firefox_for_iOS/End_Game_Checklist

Basically that means this week or early next if we want to be sure of getting the change landed and out the door.

If we miss that, we can probably get a URL change in right up until we deliver an RC to the App Store.

Basically what we're looking for is accounts.firefox.com/signin with the "Create an account" link removed, and/or an alternative splash page that goes to that amended sign in screen on clickthrough.
Before addressing the specific request here, and based on previous discussions with Shane, I think we need to commit to implementing an iOS-specific auth broker, and baking a corresponding "context" value into your config ASAP.  I see that currently you have:

    public let signInURL = NSURL(string: "https://accounts.firefox.com/signin?service=sync&context=fx_desktop_v1")!
    public let settingsURL = NSURL(string: "https://accounts.firefox.com/settings?context=fx_desktop_v1")!
    public let forceAuthURL = NSURL(string: "https://accounts.firefox.com/force_auth?service=sync&context=fx_desktop_v1")!

Let's aim to change this to use `context=fx_ios_v1` and we can use that as a flag to enable any ios-specific behaviour for these flows.  On our side, we'd just make the corresponding "iOS auth broker" act identically to the desktop broker for now, but this would give us the necessary hook to diverge between iOS and desktop behaviour, as required.

This flag, in combination with user-agent sniffing as necessary, should be all the API we need to drive any platform-specific tweaks to the flow, now or in the future.

Shane, does this mesh with what you had in mind when we talked more broadly about this broker situation yesterday?

> If we miss that, we can probably get a URL change in right up until we deliver an RC to the App Store.

If we got the above change into the current train it would hit production sometime week of 10th August.  This is the earliest we could have it ready without a full-blown fire drill and out-of-band deployment.  Does that mesh with your deadlines?  The page linked above suggests RCs are going out early August.
Flags: needinfo?(stomlinson)
Flags: needinfo?(rnewman)
Flags: needinfo?(rfkelly)
W.r.t. the specific request of hiding "/signup" links: I strongly dislike it and I want to avoid doing it.  But I trust you guys to judge how important it is, and if you tell me you need it, we can get some minimal iOS-specific styling done in the above timeframe.

Would you want this behaviour to stick around in fxa-content-server forever?  In other words, would you want us to keep hiding /signup links for FxiOS-v1 clients even after FxiOS-v2 has been released?

> so we can try to get the full state machine built or prepare for non-technical mitigations.

Whatever they are, you should prep these non-technical mitigations either way.  We won't be able to 100% prevent people from making their way to /signup.  (With more time, we could e.g. make /signup throw an error if you're on FxiOS, but that's be a terrible experience if we tried to hack it in now)
> we can get some minimal iOS-specific styling done

I'm talking literally "apply dispay:none to some links" level minimal here, and even that could easily have flow-on effects that make it complicated.  Unfortunately this fell of my radar, we were not prepared to be doing any work on it for this train.
I had a quick stab at the changes required for Comment 12 and Comment 13 to get a sense of what's possible:

  https://github.com/mozilla/fxa-content-server/compare/rfk/fx-ios-sync-tweaks

The `context` hook can be done initially with a very small change.  The no-signup-links thing was a terrible hack.

More importantly, trying it out makes it seem like a pretty crappy user experience.  If I happen to land on that page and I don't have an account, it's a dead-end with no indication of what I should do next.

A better fxa-side solution would be to make /signup rediect to an error page when context=fx_ios_v1, so there's some explanation of what's going on.  But that seems like a bigger chunk of work.  I'd strongly prefer to manage this outside of the fxa-content-server flow if possible, as in Comment 6.

Anyway, I should stop rambling here and let Shane share his thoughts, he's got much more context on the plans and possibilities here than I do!
:rfk, this is a good start for a solution. I think in the long run, a new broker will be needed so the user flow can be controlled independently of other brokers. For instance, the fx-desktop-v1 broker halts all processing after signin, the content server notifies the browser and dead ends w/o a screen transition. Fx on iOS might want a screen transition.

On top of what you have here, we need to handle users that attempt to sign in with an unknown email address. An error message is currently displayed that allows the user to go to the signup page [1]. I'm unsure of the best way to handle this case, a quick and dirty hack is to query the relier's context, see if it's fx_ios_v1, and if so, display the error as is instead of calling _suggestSignUp. A better solution is to create the above mentioned auth broker and add a function to it `isSignUpEnabled`, which returns false. the BaseAuthenticationBroker would have the same function, but return true. With this functionality, we could even do a redirect from the /signup page to /signin with a message to the user that says, "sorry, signup isn't ready yet on Fx for iOS, but will be soon."

rnewman, nalexander: Even though Nick made this request a couple of weeks ago, this kind of blind sided us because we were unaware of the coming App Store deadline. Who can I work with to tease out additional requirements and the corresponding schedule so that crunch time scrambles are avoided? Is there a meeting either myself or Edwin can sit in to hear about upcoming FxA integration work? I don't like when our team causes others stress, and I'd like to make this integration as awesome as possible!

[1] - https://github.com/mozilla/fxa-content-server/blob/cd898f5212a0426727b5e11175370fc1b84d6247/app/scripts/views/sign_in.js#L149
Flags: needinfo?(stomlinson)
(In reply to Shane Tomlinson [:stomlinson] from comment #16)
> :rfk, this is a good start for a solution. I think in the long run, a new
> broker will be needed so the user flow can be controlled independently of
> other brokers. For instance, the fx-desktop-v1 broker halts all processing
> after signin, the content server notifies the browser and dead ends w/o a
> screen transition. Fx on iOS might want a screen transition.

While we're here, Fennec will want it's on broker too, for all the same reasons.

> On top of what you have here, we need to handle users that attempt to sign
> in with an unknown email address. An error message is currently displayed
> that allows the user to go to the signup page [1]. I'm unsure of the best
> way to handle this case, a quick and dirty hack is to query the relier's
> context, see if it's fx_ios_v1, and if so, display the error as is instead
> of calling _suggestSignUp. A better solution is to create the above
> mentioned auth broker and add a function to it `isSignUpEnabled`, which
> returns false. the BaseAuthenticationBroker would have the same function,
> but return true. With this functionality, we could even do a redirect from
> the /signup page to /signin with a message to the user that says, "sorry,
> signup isn't ready yet on Fx for iOS, but will be soon."
> 
> rnewman, nalexander: Even though Nick made this request a couple of weeks
> ago, this kind of blind sided us because we were unaware of the coming App
> Store deadline.

Sorry about this.  The back story is that I did most of the iOS FxA work and then walked away from the iOS project to work on other things.  I don't think the iOS FxA code has been touched since.

 Who can I work with to tease out additional requirements and
> the corresponding schedule so that crunch time scrambles are avoided? Is
> there a meeting either myself or Edwin can sit in to hear about upcoming FxA
> integration work? I don't like when our team causes others stress, and I'd
> like to make this integration as awesome as possible!

I have an action item to investigate some rough points in the FxA login machine, so I'll be back in the area and I can be your point person for FxA integration on iOS.  We're expecting very minimal asks from the fxa-content-server team from here until we ship.
I added a new column in [1] to define how the fx_ios_v1 flow should act.

[1] - https://docs.google.com/spreadsheets/d/16Uhb8vtGB_-krMbzaq0b3XYvTWePi_xgIElL7dquohA/
Depends on: 1189296
(In reply to Ryan Kelly [:rfkelly] from comment #12)

> Let's aim to change this to use `context=fx_ios_v1` and we can use that as a
> flag to enable any ios-specific behaviour for these flows.

Filed Bug 1189296.

> If we got the above change into the current train it would hit production
> sometime week of 10th August.  This is the earliest we could have it ready
> without a full-blown fire drill and out-of-band deployment.  Does that mesh
> with your deadlines?  The page linked above suggests RCs are going out early
> August.

That works, so long as things will continue to work as they do now if we send the new context before Aug 10.


> Would you want this behaviour to stick around in fxa-content-server forever?
> In other words, would you want us to keep hiding /signup links for FxiOS-v1
> clients even after FxiOS-v2 has been released?

Not necessarily -- once the new version of the app is out, we expect almost all users to upgrade, and the ones who stick around can take what they get.

This is simply a super short-term mitigation to avoid a user creating an account on iOS without the client being finished. Our hope is that it's better for the user to be a little puzzled and go sign up on their desktop than for them to successfully sign up and end up without their data syncing (or tickle client bugs and really screw something up). If we can put up that crowd-control barrier for 2-6 weeks, then that's enough.

As soon as Bug 1167010 is done, we can kill the no-signup URL param (if it's client-controlled) or you can deploy a new train (if you control this on the server by context), and by the time it reaches users, sign up is back.


> Whatever they are, you should prep these non-technical mitigations either
> way.  We won't be able to 100% prevent people from making their way to
> /signup.

If you mean "some users will post a direct link on a forum and open it on their iPad": I'm not worried about those users. If anyone does manage to do that, things will still work (the account will be created, the client configured, and it *should* stop there). It just won't be syncing anything.
Flags: needinfo?(ckarlof)
> That works, so long as things will continue to work as they do now if we send the new context
> before Aug 10.

Unfortunately I don't think this will work.  If you send an unknown context you'll probably get the default broker which doesn't do what you want.

The patch to accept the updated context value is very small and very low risk, if it makes the difference I think we should try to backport it onto train-42 for an earlier deployment.  Shane, thoughts?

> once the new version of the app is out, we expect almost all users to upgrade,
> and the ones who stick around can take what they get.

This is very reassuring :-)
Flags: needinfo?(stomlinson)
Aye aye. Train 43 is tentatively scheduled to go out on August 10th; if all goes well with testing and the train 42 deployment, which is currently scheduled for Monday the 3rd. My hope is train 43 goes out on Monday the 10th, or within a couple of days afterwards, to fix a two outstanding bugs for the firstrun flow. Backporting a patch and having it released between Monday the 3rd and Monday the 10th will add pressure to the train 43 schedule, could cause that train to be pushed back.

Maybe it can be slipped in before train 42 goes out on Monday? Either way, jrgm should be involved in this discussion, he's the one in the best position to say what is and isn't possible with the current schedule.
Flags: needinfo?(stomlinson) → needinfo?(jrgm)
Aye, :jrgm is loaded up to the max with deployment wrangling right now :-(

FWIW I think this is the minimal change we could get away with to lay the groundword for future tweaks: https://github.com/mozilla/fxa-content-server/commit/de5c76d3f9c11088acab612941a9b690601a6ede
I don't have enough context on the timelines here.  AFAICT our options are:

1) Do nothing now, maybe add some user-agent sniffing in a future train
2) Try to rush `context=fx_ios_v1` out early next week by jamming it into train-42
3) Include `context=fx_ios_v1` in train-43 so it's ready the week after, assuming all goes well
4) Use a messaging flow like [1] to signal that we want special treatment, and leave `context=fx_desktop_v1` alone

One advantage of (4) is that you could try to ship the client code for it before we get the server stuff deployed through to production, reducing timeline pressure on our side.

This from Comment 11 gives me hope that (3) is a workable, low-risk, stress-free option:

> If we miss that, we can probably get a URL change in right up until we deliver an RC to the App Store.

But we'll need some combination of Richard, Nick and John to eliminate the unviable options from that list.


[1] https://github.com/mozilla/fxa-content-server/issues/2861#issuecomment-126342306
It sounds like the easiest thing to do is separate:

1. Add &exclude_signup=1 to our URLs or signInOnlyMode to capabilities. We can do that now. When the server code is done and deployed, things will magically work. When we're ready to support sign up, we'll land the appropriate undo-change in the client at the same time, and that'll magically work, too.

2. When you know the context is deployed, add the new context to the iOS client.
Flags: needinfo?(rnewman)
(In reply to Ryan Kelly [:rfkelly] from comment #22)
> Aye, :jrgm is loaded up to the max with deployment wrangling right now :-(
> 
> FWIW I think this is the minimal change we could get away with to lay the
> groundword for future tweaks:
> https://github.com/mozilla/fxa-content-server/commit/
> de5c76d3f9c11088acab612941a9b690601a6ede

This patch is low risk, and could possibly target a train 42.1. Does FxiOS communicate to FxA using WebChannels or FirefoxAccountsCommands? WebChannels are V2 of the desktop auth broker, FirefoxAccountsCommands are V1.
> signInURL = NSURL(string: "https://accounts.firefox.com/signin?service=sync&context=fx_desktop_v1")

FirefoxAccountsCommand AFAICT, they use context=fx_desktop_v1" and I see this in the source:

  "addEventListener("FirefoxAccountsCommand", handleAccountsCommand)"

> Add &exclude_signup=1 to our URLs

I suppose this won't break anything, and is at least an improvement over UA sniffing :-)
> Unfortunately I don't think this will work.  If you send an unknown context
> you'll probably get the default broker which doesn't do what you want.

FYSA, Emily already implemented Bug 1189296. I marked it as not ready to land until you say so.
I didn't say this explicitly, but I think separating is a good plan:

> 1. Add &exclude_signup=1 to our URLs

Do this because it won't break anything, gives us something that's better than U/A sniffing as a last resort, and is certain to be short-lived.  I'm not even going to bother bikeshedding the name of it :-)

> 2. When you know the context is deployed, add the new context to the iOS client.

We'll move ahead on this at a fast-but-sensible pace, either train-43 or as a patch release of train-42.
Depends on: 1190097
(In reply to Ryan Kelly [:rfkelly] from comment #28)
> I didn't say this explicitly, but I think separating is a good plan:
> 
> > 1. Add &exclude_signup=1 to our URLs
> 
> Do this because it won't break anything, gives us something that's better
> than U/A sniffing as a last resort, and is certain to be short-lived.  I'm
> not even going to bother bikeshedding the name of it :-)
> 
> > 2. When you know the context is deployed, add the new context to the iOS client.
> 
> We'll move ahead on this at a fast-but-sensible pace, either train-43 or as
> a patch release of train-42.

Why do we need both context=fx_ios_v1 and exclude_signup=1 ?  "fx_ios_v1" would already mean that sign up is not supported
(In reply to Vlad Filippov :vladikoff from comment #29)

> Why do we need both context=fx_ios_v1 and exclude_signup=1 ?  "fx_ios_v1"
> would already mean that sign up is not supported

It wouldn't be for the workaround in this bug; it would be so we're not reusing desktop's context, which gives us flexibility in the future.
> Why do we need both context=fx_ios_v1 and exclude_signup=1 ?

We don't.  But the client can add exclude_signup=1 to its URLs now without breaking anything, it'll just be a no-op.  Switching to context=fx_ios_v1 before it's deployed on our servers will cause things to break.

We will *not* commit to exclude_signup being an ongoing API feature, or anything more than a temporary escape-hatch.  It's only for this specific situation and only because of impending URL-freeze deadlines.  If it turns out we get context=fx_ios_v1 in production before client RC ships to the app store, we should throw away exclude_signup entirely and pretend it never happened.
Flags: needinfo?(ckarlof)
Initial support for |context=fx_ios_v1| landed in https://github.com/mozilla/fxa-content-server/pull/2865. This patch was backported to create train 42.1. If all goes well with testing, support for |context=fx_ios_v1|, with hidden signup links, should go to production this week.
Flags: needinfo?(jrgm)
(In reply to Shane Tomlinson [:stomlinson] from comment #32)
> If all goes well with testing, support for
> |context=fx_ios_v1|, with hidden signup links, should go to production this
> week.

Thanks, Shane. That'll unblock Bug 1189296.

Ryan, do you have a PR we should be watching for exclude_signup?
Assignee: stomlinson → rfkelly
Status: NEW → ASSIGNED
Flags: needinfo?(rfkelly)
Support for disabling signup when *either* `exclude_signup=1` or `context=fx_ios_v1` landed in this PR and will be part of FxA train-43 deployment:

  https://github.com/mozilla/fxa-content-server/pull/2868

That's scheduled for this week, but I haven't caught up with :jrgm yet to confirm the details.

Note that as of now, it is safe to include either or both of `exclude_signup=1` and `context=fx_ios_v1` in the URLs.  They just won't trigger the signup-disabling behaviour until the next train is deployed.

> If it turns out we get context=fx_ios_v1 in production before client RC
> ships to the app store, we should throw away exclude_signup entirely and pretend it never happened.

Does this seem doable now, or should we stick with exclude_signup=1 for initial release?
Flags: needinfo?(rfkelly) → needinfo?(rnewman)
:rnewman - The PR with this feature is [1], which should go into production today. You can see it in stage now by visiting [2] or [3].

[1] - https://github.com/mozilla/fxa-content-server/pull/2868
[2] - https://accounts.stage.mozaws.net/signin?exclude_signup=1&context=fx_ios_v1
[3] - https://accounts.stage.mozaws.net/signin?exclude_signup=1&context=fx_desktop_v1
(In reply to Ryan Kelly [:rfkelly] from comment #34)

> Does this seem doable now, or should we stick with exclude_signup=1 for
> initial release?

I'm happy to continue with exclude_signup=1 for this particular hack. Using the correct context is just the Right Thing To Do® going forward.

Also using *only* exclude_signup is nice, because developer builds will send the correct context but *not* exclude_signup, so devs (read: me) can still test the correct empty-server flow :)


(In reply to Shane Tomlinson [:stomlinson] from comment #35)
> :rnewman - The PR with this feature is [1], which should go into production
> today. You can see it in stage now by visiting [2] or [3].

Thanks, Shane! I'll try this out.
Flags: needinfo?(rnewman)
Verified on stage. Jumps straight to sign in.
FTR, uireview+ from tecgirl.
> Also using *only* exclude_signup is nice, because developer builds will send the correct
> context but *not* exclude_signup, so devs (read: me) can still test the correct empty-server flow :)

Interesting point, I hadn't considered this.  The current behaviour of fxa-content-server will not support it because it disables signup when *either* exclude_signup or the ios context is present.  Given the ask above, perhaps we should change that to make exclude_signup the *only* way to trigger this behaviour, keep it around for a few months while you dev, and aim to remove that hackery by christmas.

In any case, I'm glad we've got something in place that you can ship to the app store and we can tweak behind-the-scenes over the next couple of cycles.
(In reply to Ryan Kelly [:rfkelly] from comment #39)
> Given the ask above, perhaps we should change that to make exclude_signup the *only* way to
> trigger this behaviour, keep it around for a few months while you dev, and
> aim to remove that hackery by christmas.

+1 on that.

> In any case, I'm glad we've got something in place that you can ship to the
> app store and we can tweak behind-the-scenes over the next couple of cycles.

It's much appreciated! I owe you lot some beers and/or tacos and/or coffees.
(In reply to Ryan Kelly [:rfkelly] from comment #39)

> perhaps we should change that to make exclude_signup the *only* way to
> trigger this behaviour, keep it around for a few months while you dev, and
> aim to remove that hackery by christmas.

If our stated goal is to remove exclude_signup, I would rather not use this
approach. API options that live for more than an extremely short period end
up being supported forever. Can we just use two different contexts, fx_ios_v1
means singup is not supported, fx_ios_v2 means it is. We reduce the API surface
area, and the version bump blatantly indicates something major has changed.
Another option to consider is whether the `capabilities` approach is applicable, and could be used here. We could just query the UA. If it says it supports signup, we enable signup. If it responds negatively, then we don't.
(In reply to Shane Tomlinson [:stomlinson] from comment #41)

> If our stated goal is to remove exclude_signup, I would rather not use this
> approach. API options that live for more than an extremely short period end
> up being supported forever.

This will be a very short period -- until the end of September most likely, and November at the latest. There's no need to continue supporting this once we get v1.x/v2.0 out the door, and if it breaks before then, so be it: this is a hack to avoid a limitation, not a real API option.

(The guarantee: Karen would kill me if we were in the market for months without supporting account creation from the device.)


> Can we just use two different contexts, fx_ios_v1
> means singup is not supported, fx_ios_v2 means it is.

That would work for me, but I don't think you can safely get that deployed in production by tomorrow. We hope to cut an RC on Friday, and we've already tested what's in stage (and now prod).
As far as I can tell, this is done in prod. Ryan, close this when you're happy!
> As far as I can tell, this is done in prod. Ryan, close this when you're happy!

Yes, let's follow up in follow-up bugs.  I filed [1] to formulate and implement a plan for the eventual removal of exclude_signup=1.

I see the following URLs in our source and unless you tell me otherwise, I'll assume this is what's been shipped in the RC and will go out to users-we-have-to-support in the wild:

    signInURL = NSURL(string: "https://accounts.firefox.com/signin?service=sync&context=fx_ios_v1&exclude_signup=1")!
    settingsURL = NSURL(string: "https://accounts.firefox.com/settings?context=fx_ios_v1&exclude_signup=1")!
    forceAuthURL = NSURL(string: "https://accounts.firefox.com/force_auth?service=sync&context=fx_ios_v1")!

[1] https://github.com/mozilla/fxa-content-server/issues/2950
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to Ryan Kelly [:rfkelly] from comment #45)

> I see the following URLs in our source and unless you tell me otherwise,
> I'll assume this is what's been shipped in the RC and will go out to
> users-we-have-to-support in the wild:

Correct.

Thanks to both of you for getting this done and out the door!
You need to log in before you can comment on or make changes to this bug.