Improve "classic" verification page

[kiootic]

Currently, the verification email includes a link, which mark the user as verified when opened. This is problematic for security reasons:

• GET request should not cause side effects
• User should log-in before verification to ensure a typo in email would not cause account takeover

Therefore, to support a secure verification page, we need to require manual action & authentication before verification. However, due to complex login behaviors & methods, and the use of header session transport, it is impractical to implement a generic login page at the moment.

For now, we'll mitigate the existing problem by:

• remove verification GET endpoint
• remove the link in email and show only the code

[chpapa]

remove the link in email and show only the code

This is a very weird default behaviour?

remove verification GET endpoint

This could be mitigated with a GET page that requires another click?

Instead of removing them and make the default experience so weird, actually are we using cookies on JS SDK by default? If yes maybe it is just easier if we provide a default URL that respects the cookies, show a button for a click to verify the code, and redirect users to error page if not logged in (or even better, create a redirect URL setting for where to redirect if logged in is needed)

Then the default experience is more complete...

For users use auth token, we shall explain in our guides and user portal that the link doesn't work for auth token and they should implement the URL on their own (assuming auth token is not the default option, so people switched it knows what they're doing?)

That seems way better than removing the whole thing...

[chpapa]

BTW, for big feature changes... please put it on feature repo instead of in individual repo so it would update our spec and I don't look at every issues here (it just happen we discussed this today so...)

[kiootic]

The team had discussed on that, and we think that:

• removal of these behavior will indeed make default flow incomplete, but we are unable provide a reasonable UX for it without lots of work, otherwise there would be dead-ends in the verification flow.
• it is expected every apps would customize this flow, therefore the impact is minimal, even if the default flow is somewhat incomplete.
• we do not expect the verification page to be gone forever, and we can revisit it when the proposed AuthKit is completed.

[kiootic]

For reference, here's some problems we need to address if we want to keep a complete default flow:

• We'll need to read the login state at the verification form page, however we can't do this reliably if header session transport is used. If we only allow cookie transport to be used with default flow, we'll have two UX, which makes an inconsistent developer experience (i.e. 'if you use header transport, you make the verification flow yourself')
• We'll need to allow user to login if not already logged in, however we don't have a generic login page, so we'll have to redirect to developer controlled login page.
• We can add a config option for URL of login page, however most likely developers would customize UX of email template and verification page, so we'll be adding an option which would be unused most of the time. Personally speaking, I think the maintenance burden would outweigh the usefulness.
• After redirecting to login page and user is logged in, where should the user be redirected to? Most likely developer would want to redirect back to verification form page, yet the form page is not a public API at the moment. We'll need to publicly document this form page and committed to maintain this page, which as mentioned before, would most likely went unused.

[chpapa]

The problem is the current way we propose to just send an email with verification code, is very half-baked and make the whole experience very incomplete for both type of developers: Developers who don't want to customize the UX or developers who want to.

• It is incomplete for people who don't care the details of UX. Some MVP apps or software don't care too much and would be happy to use the default UX, no customization at all. If we just pass the verification code in the email, it is incomplete flow and they must develop their own verification page.
• For developers who want to customize the UX, the way to customization is, I need to figure out how to do it with Skygear half-baked approach, I need to learn a lot of how skygear works until I can customize it.

I'm thinking maybe the best way to move forward is to just leave this feature as-is, aka, we don't care if the GET request has a side-effect, and also don't care if verify the code without auth is a problem (yea I know I'm the one who question this in the first place).

So at least we have a "basic flow" that Marketing team can do the demo first, and don't look dumb as if a basic feature of verification by email is not even there.

Than we can come back and fix this later.

[chpapa]

So here is what I would propose:

1. We leave this feature as-is for 2.0 launch, with the potential problem for the verification link don't verify the authenticated session and/or link triggered unintentionally / GET side-effect; Consider it mostly for demo purpose.
2. For 2.2, we fix it as follows (Jan / early Feb?):
   1. We develop the "AuthUI" #370 which should be the default way we encourage Skygear Users to use auth IF they don't need much customization, and in #370 our verification link will be implemented "correctly"
   2. We improve the "classic verification link" in one of the following way:
      • We improve this verification link without GET side effect, aka people need to click once in our default UI to actually verify the account; OR
      • We improve this verification link which requires cookies-based session, without GET side effect, and tell people who use auth headers to implement their own OR use #370

I think we need this trade-off to make Skygear Auth demo-able after 2.0 launch.