Good call - I replaced the following environment variables in my local environment:
CORS_ORIGINS=https://app.forestadmin.comDATABASE_REJECT_UNAUTHORIZED=falseDATABASE_SSL=trueDATABASE_URL=...…and sure enough, I’m loading production data perfectly fine! I even tried it with NODE_ENV=production to make sure. Could any of the values of the remaining environment variables in production be causing an issue?
APPLICATION_URLFOREST_AUTH_SECRETFOREST_CLIENT_IDFOREST_ENV_SECRETOk,
All the environment variables you mention are ok because we can see requests incoming inside your server.
I ask myself if your code is really the same between prod and dev.
Can you double/triple-check that? 
Can’t you have a try without a complete no-custom code version on the production?
Regards
Yes, it’s the same. Heroku auto-deploys off master and I just confirmed that the latest deploy commit matches what I have locally.
Since my project thinks nothing is deployed to production (see my other thread), do you think it’s worth re-deploying to production, using development as the base?
Hi @txtjournals,
Do you have the same version of postgres on dev and on production 
?
They’re both v12, but I can also point my local instance at the production database and it works fine.
Hi @txtjournals,
So many questions and messages on this thread…
Be sure we’re sorry we couldn’t help you out with your problem yet!
Since my project thinks nothing is deployed to production (see my other thread ), do you think it’s worth re-deploying to production, using development as the base?
→ Definitively worth a shot!
Let me know how this ends up.
You might want to delete the remote environment called “Production” before, just in case it doesn’t have any value to you and if it causes some troubles in the deploy to production process.
Hi @anon34731316 - thanks for chiming in.
I removed the exciting remote environment, launched the production environment (updating the environment variables on Heroku), and cleared cache. Now I can’t authenticate to this new environment:
HTTP Response:
Error: invalid_grant
Error String: You are not allowed to access to this client
State: {"renderingId":88983}
No errors on the server and can confirm that backend is receiving (and responding to) the requests.
Hi @txtjournals,
Could I ask you to open your Network tab, and share with me the call to https://api.development.forestadmin.com/oidc/auth?client_id=<long_token>. I am particularly interested in this client_id parameter so I can check if the data is correct.
Thank you
Hi @anon90145840,
I don’t have a call to https://api.development.forestadmin.com/oidc/auth, but rather to https://api.forestadmin.com/oidc/auth (will send in DM).
The GET results in a 302 with a redirect to https://<My App>.herokuapp.com/forest/authentication/callback?error=invalid_grant&error_description=You+are+not+allowed+to+access+to+this+client&state=%7B%22renderingId%22%3A88983%7D
Note: this authentication error began occurring after re-deploying the project to production. Is there perhaps a conflict between this new production environment and something old in the database since the DB was originally from an old remote environment?
Hello @txtjournals,
Looking at your client id, it looks like you configured your environment_secret with the secret key of an environment named Production that you deleted at 2021-04-20 17:26:50.917+00 and you re-created one at 2021-04-20 17:39:10.404+00.
Both the old and the new one share the same URL, but the environment secret must be changed.
Please check that the environment variable you provided to your liana matches the one that is visible in the environment’s settings on Forest Admin.
Hi @GuillaumeGautreau - thanks for your help on this!
Yes. I had updated all environment variables when I re-deployed. I suspected this could be the issue, so I re-checked and restarted the instance a half dozen times already. Could the old environment secret be cached in the database somewhere that needs to be cleared out?
Hello,
No, the env_secret is directly retrieved from the initialization variables, it’s not cached anywhere
@GuillaumeGautreau Any other ideas then?
Perhaps the FOREST_CLIENT_ID environment value is wrong on Heroku…is this what you’re saying? If so, is there a way to recreate?
In fact you definitively need to regenerate the FOREST_CLIENT_ID with the new env secret. I did not realized that you could use a fixed value for this parameter.
@GuillaumeGautreau Is there a guide on how to do this correctly?
You have to follow this docs: https://docs.forestadmin.com/documentation/how-tos/maintain/upgrade-notes-sql-mongodb/upgrade-to-v7#setup-a-static-clientid
And you were right about the cache, there is some cache involved regarding this value. I mixed up 2 different topics that were close.
Could please make sure that you’re using the last version of forest-rails, we recently released a fix regarding this issue about the cache.
Back to square one. Authentication issue is resolved, but now I’m still receiving the initial error of “Cannot reach your data”.
@GuillaumeGautreau - we’re on Node, not rails.
To recap:
What’s a good way to confirm DB connection to 100% rule this out? Any other ideas?
Thanks for your help, everyone!
Thanks for the update @txtjournals,
Can you copy/paste the details about HTTP request that are failing, from the network tab of your browser’s developper tools?
It’ll give us details on the reasons of this failure.
Thanks