Describe the bug

Running the terminus build:project:create command described in the documentation results in an error message.

  The "--profile" option does not exist.

Reproduction

Use Terminus 3 and install the Build Tools plugin using the documentation:

terminus self:plugin:install terminus-build-tools-plugin

I think the issue is that this installation mechanism brings in the most recent tagged release of Build Tools (made in January) and the profile option was added in February/March.

I think the needed resolution is a new tagged release of Build Tools that is installable when running terminus self:plugin:install terminus-build-tools-plugin

Logs

No response

Which packages/starters are effected?

• next-drupal
• gatsby-wordpress
• drupal-kit
• wordpress-kit
• documentation
• monorepo

Severity

Blocking all usage of Decoupled Kit

Additional Information

It's probably possible to work around this issue but installing a dev version of the plugin. I knew how to do that in Terminus 2. My few minutes of attempts in Terminus 3 have failed. I think with how small the resolution needed is, we should just cut a new release of Build Tools rather than documenting a work around that puts customers on a branch instead of a tagged release.

Describe the problem

This starter kit currently handles authentication and authorization from the perspective of a machine user that sources data from Drupal. It would be desirable to demonstrate an example for user authentication as well - a user can authenticate via a login form and as a result gains access to specific resources based on their Drupal account.

Describe the proposed solution

Provide an OpenID based user authentication option.

Drupal:
Assumes that Simple oAuth and OpenID Connect are installed.

Next:
Using NextAuth

High level flow:

• User authenticates via next-auth / OpenID provider
• This information is used to authenticate with Drupal
  ** OpenID connect will create a Drupal account the first time a user authenticates if it does not exist. What I'm not clear on is if this will happen when accounts are created via API based registration requests and if the next-auth token provides enough information to make SSO with Drupal possible.
  ** If OpenID can't create accounts via API requests, this step instead would have to try to authenticate or check for the existence of a Drupal account (as the machine user,) and if the account doesn't exist, create an account.
• A user specific Drupal State store is created for that user. All user specific requests are made through that store.

Drupal State:

• For user authentication Drupal will need to be enhanced to support the password grant type. A related issue exists here: https://www.drupal.org/project/drupal_state/issues/3263740

Alternatives considered

There are many other auth methods that could satisfy this, but this approach has the benefit of taking advantage of Drupal's simple oAuth Ecosystem.

Importance

It would make my life easier

Additional Information

No response

Expected behavior

• It's expected that creating a Drupal site using the steps described in the documentation will result in a site that is compatible with with the Next.js starter site

Actual behavior

• The Next.js site throws a build error because it expects recipe nodes but the starter Drupal site does not have that content type.

Steps to reproduce the problem

1. Create a Drupal site using the steps in the documentation
2. Use the Pantheon dashboard to create a Next.js site to create from the newly created Drupal site.
3. See a build error

Step #9 - "build-auto-ssr-private-build": Error: Invalid objectName.
Step #9 - "build-auto-ssr-private-build": Check that node--recipe is a valid node in your Drupal instance or local store

Suggested Resolution

• Update one or more of

1. The Drupal starter (to include a recipe content type)
2. The next.js starter (to not use a recipe content type)
3. The documentation for combining the two (maybe document how spin up Umami if that's what the Next.js starter presently expects)