Wp-calypso: Investigate where and how we should provision temporary account/site

[ramonjd]

Subtask of EPIC #38702

We need to agree on how we're going to create a temporary user account and site.

The path of least resistance might be to chain two HTTP calls to users/new and sites/new. Changes to these endpoints will probably be necessary, e.g., to suppress marketing emails, add meta/flags to temporary accounts and sites.

Questions

Systems/security

• Are there any security aspects or risks we need to consider with creating temporary accounts/sites. Let’s ask Systems/SecOps when we have more technical information.
• We should think about cleaning up unused temporary sites, including how and when we should do so. It might guide how we flag accounts/sites.
• What should we use as an email address? Do we need one at all?

Request for advice post: pMz3w-aWr-p2

Legal/privacy

• What if a user creates a temporary account and inputs personal data? How can we reconcile that with the GDPR for example? Ask the legal eagles.

Analytics/marketing

• Would we be affecting any of our stats/analytics with all these temporary account creation/site creation? Maybe we can ask data to add exceptions?

Technical implementation

• Where in the flow should we provision the temporary account? Immediately? Or immediately before the user arrives at FSE? It might be best to provision the account/site immediately before we load FSE, so we don't have to headstart the site with the post body content as well. See: pbxlJb-4a-p2#comment-16
• How should we bake the HTTP calls into the Gutenboarding code (POST to users/new sites/new)? Let's ask @Automattic/luna
• Following on from the above question, should we use the existing wpcom.undocumented() methods usersNew and sitesNew (for built-in authentication)?

Assumptions

• Provisioning should be transparent and occur in the background
• We need to somehow prevent the creation of multiple temporary accounts/sites in one session, e.g., checking a session cookie, validating the user id
• We get agreement on any data structures with Luna, e.g., persistent state objects, response formats and types

Relevant links

Temporary account and site generation: initial musings: pbxlJb-4a-p2

[roo2]

oops 😊

[sirreal]

• How should we bake the HTTP calls into the Gutenboarding code (POST to users/new sites/new)? Let's ask @Automattic/luna

Should this be part of a @wordpress/data data store? We have some patterns that could be followed there, although we don't have any update-type (POST) usage yet. The gist would be to dispatch an action from a store.

Have a look at the new @automattic/data-stores package. Happy to chat more about this or other options.

should we use the existing wpcom.undocumented() methods usersNew and sitesNew (for built-in authentication)?

What do you mean by "built-in authentication"? We have a precedent in Gutenboarding to avoid pulling in dependencies directly from Calypso source code, as this tends to lead to a dependency graph that we don't understand and can't control the bounds of, affectionately referred to as "Calypso soup." That precedent and the goal of avoiding bloated bundles —I believe the wpcom lib is not tree-shaking friendly— likely precludes its usage.

Mentioned functions for reference:

https://github.com/Automattic/wp-calypso/blob/e3654a578c59a835459f7a7fe10ce0aada50def4/client/lib/wpcom-undocumented/lib/undocumented.js#L1344-L1357
https://github.com/Automattic/wp-calypso/blob/e3654a578c59a835459f7a7fe10ce0aada50def4/client/lib/wpcom-undocumented/lib/undocumented.js#L1462-L1481

[ramonjd]

Thanks for the info @sirreal !!

Should this be part of a @wordpress/data data store? We have some patterns that could be followed there, although we don't have any update-type (POST) usage yet.

At first sight, yes. I did hack around with creating a POST variant in the @automattic/data-stores package, and got it and the associated state modules firing off fine based on the existing architectural examples.

I only moved my experiment to landing/gutenboarding so I could more easily import wpcom relatively. 😇

We'll look at implementing our stuff there. 👍

What do you mean by "built-in authentication"?

This was a bit of a covfefe on my part.

It's the _path-of-least-resistance_ approach of _"since it's already written and set up to send REST API tokens"_ and so on, why don't we use it?

I'm also assuming a lot based on some very shallow tracing, and the observation thatwpcom.js ships requests through a proxy iframe

I don't yet know how much we'd need to pull over to make it all play nice. Maybe nothing. I'll need to school myself a bit harder on that.

We have a precedent in Gutenboarding to avoid pulling in dependencies directly from Calypso source code

Good to have confirmed, cheers.

[ramonjd]

On hold until we come up with a solution that works for everyone.

See discussion at pMz3w-aWr-p2

[ramonjd]

Closing for now while we work on https://github.com/Automattic/wp-calypso/issues/38701