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
?