Urgent - Cannot login anymore after the update

We upgraded from 7.2.2 to 7.6.5 and we can’t login anymore.

The request to my server works:

Started POST "/forest/authentication" for 172.18.0.1 at 2022-06-21 14:41:13 +0000
Processing by ForestLiana::AuthenticationController#start_authentication as */*
  Parameters: {"renderingId"=>"25560"}
Completed 200 OK in 161ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 1433)

The one to yours fails

We updated our gems and rails from 6.1 to 7.0 as well.

I checked the changeling, nothing mentions a similar problem. Any idea what is broken?

Hi @sayduck-daniel

Can you confirm your production server is down, or is authentication failing in development?

Hello @sayduck-daniel,

I checked our logs, and our server is rejecting this call because the property client_id is invalid. As you can see, this id is a signed JWT, and in your case the token contains valid data but the signature is incorrect. I suppose that some characters at the end of the initial values have not correctly been copy pasted in some manual changes made during the upgrade process.

Do you have a config variable named forest_client_id? Could you re-do the procedure to generate it as explained in the docs?

If you do not use multiple servers for your agent, you can remove this configuration value and clean your cache. The agent will generate an id at startup.

There is no mention of forest_client_id in our codebase.

forest_liana.rb content:

ForestLiana.env_secret = ENV.fetch('FOREST_ENV_SECRET')
ForestLiana.auth_secret = ENV.fetch('FOREST_AUTH_SECRET')
ForestLiana.application_url = ENV.fetch('SAYDUCK_API_URL')

ForestLiana.integrations = {
  stripe: {
    api_key: ENV.fetch('STRIPE_SECRET_KEY'),
    mapping: [
      'Customer.stripe_identifier',
      'Plan.stripe_identifier',
      'Subscription.stripe_identifier'
    ]
  }
}

I added the client_id and now it is working.

Can you try to clear the cache from ruby, to force the server to register again?

Also, if this does not fix the issue, I would need the external IP address from your server, and the approximate time you restarted it, to locate the call in our logs. You can send this by direct message.

Last test: does it solve the issue to downgrade again to 7.2.2?