feat(passport): custom domain

[szkl]

Description

Introduces a utility function named getCookieDomain. If the request host is
not matching the defined HOST then the request will be checked for a custom
domain if the request has clientId in the host metadata.

The server entry point implements a similar process to check the custom domain
status at the beginning of the request lifecycle.

Related Issues

• Closes chore(passport): Implement Custom domain support #2194

Testing

• Manual

• Create a custom domain in the console for a published application

• Do the validation steps and finally create the CNAME record

• Visit passport using the custom domain and login

Checklist

• I have read the CONTRIBUTING guidelines
• I have tested my code (manually and/or automated if applicable)
• I have updated the documentation (if necessary)

[szkl]

Should the cookie SameSite attribute be Strict for custom domains?

[betimshahini]

Here's a thought, not sure if we should do this but worth putting out there: if we're to set a acceptedDomain metadata prop when we store the clientId on there, we'd be able to check both things without having to call starbase at all. I'm thinking the headers are injected more quickly in the request compared to the roundtrip time of passport->starbase->DO and back. Headers would get bigger is one downside, and we don't know the consistency/reliability characteristics of the metadata store. WDYT?

[szkl]

We could do that but it'd be a redundant check. The request host and the host in the metadata would be the same assuming Cloudflare wouldn't make a mistake. I think it is okay to try it out during beta.

[szkl]

The other condition checked is the status of the domain which depends on the validations. It can be ignored only as long as Cloudflare passes traffic over the custom hostname.

[betimshahini]

Maybe call this DEFAULT_HOST or PASSPORT_HOST or something, for clarity.

[szkl]

Done.

[betimshahini]

Should the cookie SameSite attribute be Strict for custom domains?

I think some of the callback redirects won't work with Strict. IIRC that's the reason why kept it as it currently is for non-custom domain passport.

[betimshahini]

@szkl As discussed, this PR should prevent access to /settings route and its children when accessed through custom domain. This will be revisited later under #2337

[szkl]

@szkl As discussed, this PR should prevent access to /settings route and its children when accessed through custom domain. This will be revisited later under #2337

I found out that a request to /authorize is needed to complete the authentication for an application. Should Passport make that request if the initial request is for a custom domain? Should the application redirect to the passport authorize endpoint on the custom domain?

[szkl]

Pending a test on the development environment.