Update signup/confirm flow to handle showcase/bob users

[leichter]

Bunch of things that need to be updated to allow bob users to signup using the same endpoint - primarily the signup and confirm endpoints should likely take a target param (query param) that denotes whether a user is signing up from selfie or the showcase. This should then be used for several things:

• deciding which roles + policies to give the new user (config.newUserPermissions should have different sets for each target)
• deciding which activation link to use in (config.emails.activationTarget should be split into a hash with different values for each target)
• the accountCreated, accountActivated, and resendActivation watchman events that are produced need to use this target (currently they are hardcoded to 'selfie' (should double check if there's anywhere this needs to be used, not sure I got everything)

Some of the email-related changes may need to be done in watchman as well (cc @ScottBouloutian )

[ScottBouloutian]

Some watchman emails currently accept bob as a target, but I don't believe this is the case for the account emails, but it could be. Are you thinking we would want this target to be showcase?

[leichter]

I think that's what @minznerjosh wants to use going forward in place of bob

[minznerjosh]

Correct.

[leichter]

Note: the target query param should be set for any non-CRUD endpoint in the userSvc and auth svc, namely:

• POST /api/auth/login
• POST /api/auth/password/forgot
• POST /api/auth/password/reset
• POST /api/account/user/signup
• POST /api/account/user/confirm/:id
• POST /api/account/user/resendActivation
• POST /api/account/user/email
• POST /api/account/user/password

Note that currently, the POST /api/auth/password/forgot takes the target param from the request body, and the POST /api/auth/login endpoint infers from the target based on whether or not the user has external === true. This will continue to be supported for now, but going forward, clients should be sure to set the target query param.

cc @minznerjosh @howardengelhart @sqmunson

[howardengelhart]

@leichter - rather than using a query param can we use the hostname on the request? We're planning to put SSB sites under their own domains.. apps.reelcontent.com .. etsy.reelcontent.com ..etc.. could we use this rather than a query param?

[leichter]

After doing some initial investigation, it looks like we probably can't - the host header gets rewritten to the ELB's hostname (e.g. 'elb-rc-api-service-staging.reelcontent.com') by the time the request gets to our Node server, and I can't find any other header or property on the express req object that may have the original header. There may be some futzing with Cloudfront/ELB settings we can do to somehow preserve the original host, but given that we use this target param in a bunch of places already, I'd rather move forward with this plan for now at least.

[leichter]

Ok checked into this again once the Cloudfront changes went through and it looks like updating Cloudfront to forward the host header will solve the above issue, so we will be able to use the hostname from the request. In the services, that can be used to set this target param that then gets used for determining which emails to send + policies/roles to apply.

cc @howardengelhart @minznerjosh

[howardengelhart]

Great!