Cli "schema:apply" fails with 401 when using FOREST_ENV_SECRET credentials

The toolbelt, when used under a CI/CD headless scenario could not complete the scehma:apply deployment and fails with an HTTP 401: Unauthorized error.is thrown.

Expected behavior

The tools should apply the schema and complete it with a success code even if the schema apply is asynchronous.
The tool should be able to skip “token validation” when using the credentials from the FOREST_ENV_SECRET env variable since this specifically means we have credentials to access the env even if not via a specific user login. (it’s a tool running this command).

Actual behavior

the tool executes the schema apply using the credentials from the environment variable FOREST_ENV_SECRET but when trying to check the job status it looks for a login token locally and unable to find it. This leads to an empty “authorization bearer token” header on the /api/jobs/JOBID api call that fails with a 401 HTTP error.
Finally, the tools throwes ane exception failing the entire command (although the schema apply actually succeeds to complete asynchronously).

Relevant places in the code.
Calling the job-status API
Using auth token to authenticate job status call

Failure Logs

Execute forest schema apply
Reading "./.forestadmin-schema.json"...
Using the forest environment secret found in the environment variable "FOREST_ENV_SECRET"
Sending "./.forestadmin-schema.json"...
HTTP 401: Unauthorized

Context

Please provide any relevant information about your setup.

  • Package Version: forest-cli v1.6.0

Hi @Yoad_Snapir,

You are totally right on your analysis, and I’m easily able to reproduce with all the details you provided, thank you! :pray: .
The job is launched and the actual /api/jobs/:jobId fail with a 401 since no token is provided. I’ll open a ticket on our side to address this issue.

Thanks for reporting this, and we’ll let you know once this is fixed. Sorry for the inconvenience

2 Likes

Hi Guys,
So our build process is now completely broken.
I think while attempting to fix the above:

Now the tools stops and asks for a login - this tool is run from our build server to apply the schema after the successful deployments.
This means you cannot automate schema:apply without specifying a specific user email/pass inside the build process - this is probably not what you want. email/pass tend to change or removed - build bots keep on working.

Can you please fix this so we can apply the schema in a headless environment? I think either allow the tool to “poll” the success of the operation with the same ENV secret or allow to skip the “polling” in headless cases using a flag…

1 Like

Hi @Yoad_Snapir,

It is definitely more consistent to have all commands authenticated (schema:apply was the only one “public”).
On the long term we should provide API keys/tokens to do such operations with scripts.

About the current situation, what about running a forest login command before the forest schema:apply command in your script?
Something like:

forest login --token=MY_FOREST_SESSION_TOKEN
forest schema:apply

Thanks @arnaud!
Indeed eventually I did a “login” step before the schema:apply step - this is a temp workaround.
The thing is - the “FOREST_SESSION_TOKEN” can only be generated from a user’s “email+pass” login (or google’s login but that’s even worse to accomplish headless).

So, I basically have to rely on a frontend user authentication mechanism to drive an unattended service. What if I reset my personal passwords? Then all builds fail again.

The Liana server, when it starts, has the ability to apply the schema automatically (no login required). We cannot allow this automatic schema application by the server startup, so we have to use the CLI. Can’t we do the same like the server? just “on demand” from the CLI tool? This is probably the behaviour we need the most.

Hello @Yoad_Snapir :wave:

As @arnaud stated, the best you can do now is to perform a login before running any script to contact our servers. Indeed, using a personal account is not ideal. What about using a dedicated account ? Such as CI account with its own password with access to your project ? Having a dedicated account would bypass problems you could have with a personal account.

Regarding

You can use DISABLE_AUTO_SCHEMA_APPLY as an environment variable to stop your generated project from applying new schemas automatically.

Does this help ?

Steve.

1 Like

Thanks @Steve_Bunlon,
I am performing the login ATM using my account and I do think it’s a workaround not an eventual solution.
I see two problems with using an account with Login/Pass form of authentication:

  1. Cost - we pay per seat - deployment should not cost us another seat
  2. Interactive User credentials usually provide a different set of authorizations compared to what a deployment service account would need. The credentials are set in the CI/CD and could lead to a security problem

Reg, DISABLE_AUTO_SCHEMA_APPLY - we are using it to stop auto deployment - this is why we need “schema:apply” tool to do it manually. All I am saying that if the server can do an apply of schema without needed user/pass login - so does the toolbelt need the same ability.

It’s your call of course, but that’s my point of view and hope this helps!

2 Likes

@Yoad_Snapir Thanks for your response and your feedback.

I understand your remarks (the costs of such CI configuration, and the personal account to run CI/CD)

Sadly this is the best I can propose so far.

Let me add your feedbacks on our product board and we will work on this to improve CI/CD using Forest.

Thanks again for your feedbacks !

Steve.