feat: Allow AEM CLI to obtain site token

[andreituicu]

Changes:

1. Allows Helix CLI to initiate a login process to obtain transient site tokens from Helix Admin
2. The login process can be initiated in 3 ways from helix-cli:
   2.1. Automatically: the proxy in the CLI notices a 401 or 403 response during navigation and redirects the user to Helix Admin for login. This is done only once per CLI execution.
   2.2. Manually(User Friendly): If for some reason the automatic way didn't work, the user will have the opportunity to initiate the login flow every time a 401 or 403 error page is being displayed, as they include a link.
   2.3. Manually(Forced): going to /.aem/cli/login will immediately start the login flow.
3. The login process is initiated by redirecting the user to the Helix admin as follows:
   3.1 The path is the site where we want to login on the main branch https://admin.hlx.page/login/{org}/site}/main. The org and site are extracted from the proxied url.
   3.2 There is a query parameter for letting Helix Admin know this is the aem-cli (client_id=aem-cli)
   3.3. There is a redirect uri parameter for letting Helix Admin know where the cli runs and waits for a response (redirect_uri=http://localhost:3000/.aem/cli/login/ack - only the port can vary)
   3.4 There is a state parameter generated by the CLI and returned by Helix Admin as-is, so the CLI can know that the token it received corresponds to a login flow that was initiated by it.
4. Helix Admin will do the necessary authentication and authorization operations for the end user and if everything is ok:
   4.1 it will send a POST request to the ACK endpoint with the transient site token and the state.
   4.2 redirect the browser to the same ACK endpoint, when the POST request is finished.
5. The ACK endpoint will receive the token, use it and store it into the .env file only if the state matches what it sent at the beginning of the login flow, otherwise it will discard it.
6. When the browser is redirected to the ACK endpoint, this will either:
   6.1. redirect to / if everything was successful
   6.2 display an error corresponding to what went wrong during the login flow.
7. The CLI will additionally verify that .env file is ignored by git and add it to the .gitignore file otherwise, to prevent tokens from being stored in version control.

[github-actions]

This PR will trigger a minor release when merged.

[andreituicu]

Reminder to switch to the production admin url, before merging.

[tripodsan]

Question: Ideally, .env would've been already present in .gitignore from the boilerplate. Created adobe/aem-boilerplate#441, but this will unfortunately not add it to .gitignore retroactively for projects that already copied the boilerplate. Maybe another file under .hlx/ would be more appropriate to store and read the token from?

on the one hand, I think updating gitignore as mentioned in step 7 is enough....
but, otoh, I don't like too much, that .env is modified, as this "belongs" to the user. maybe having a single .hlx-auth-token file be more transparent and less intrusive.

[andreituicu]

but, otoh, I don't like too much, that .env is modified, as this "belongs" to the user. maybe having a single .hlx-auth-token file be more transparent and less intrusive.

Sounds good to me, we can put it .hlx, because it's been in .gitignore since the beginning of the boilerplate ( https://github.com/adobe/aem-boilerplate/blame/main/.gitignore#L1C5-L1C5 ) and have .hlx/.hlx-auth-token. Let me give that a try.

The only small concern I have is that .hlx isn't removed from the boilerplate .gitignore, because of the old branding. 🙂

LE: Done in 4ae5777.