New Forest Admin users forbidden from accessing data

Problem description

Hi, I upgraded to the new admin agent last October and it’s been smooth sailing since then. Yesterday, however, I created a new user for the first time since the migration and when logged in as the new user, I see the following warning whenever I try to access the data in any collection:

For reference, the project has only one role, “operations”, which as you can see has the following permissions for each collection:

The new user also has the operations role, so I’m unsure as to why they’re unable to read / write collection data and what I can do to fix this issue. I assume this is related to the upgrade to the new agent as I believe this is the first new user I’ve made since then but I can’t be certain. Please advise on how to address this issue - thank you for the help

Context

  • Project name: …
  • Team name: …
  • Environment name: production
  • Agent technology: nodejs
  • Agent (forest package) name & version: @forestadmin/agent 1.51.0
  • Database type: postgreSQL
  • Recent changes made on your end if any: upgraded to new agent last October

Hello @EIdev !

Thank you for contacting us!

To help us investigate your request efficiently, please provide:

  • Your project name
  • Your team name

Best regards,

Hello,
Could you check in your agent variables if the instantCacheRefresh variable is set to false ? By default, the instantCacheRefresh is true and we recommend to enable it !

Are you using a reverse proxy like Nginx ? In case of true, could you add this config in your nginx file :pray: :

fastcgi_buffering off;
proxy_buffering off;

Best regards,
Alban

Hi,

Here’s the code for creating my forest agent:

const agent = forestAdmin.createAgent({
  authSecret: process.env.AUTH_SECRET,
  envSecret: process.env.ENV_SECRET,
  isProduction: process.env.NODE_ENV === "production",
  schemaPath: path.join(__dirname, "../.forestadmin-schema.json"),
});

As you can see I don’t specify any value for instantCacheRefresh, so it should be set to the default value of true.

In terms of load balancers, I’m not using nginx but I am using a load balanced Fargate service with AWS for the forest admin service. Here is the relevant AWS CDK code (with values removed):

const forestService =
  new ecs_patterns.ApplicationLoadBalancedFargateService(this, "forest", {
    cluster,
    certificate,
    taskImageOptions: {
      image: ...
      environment: {
        DATABASE_URL: ...
        AUTH_SECRET: ...
        ENV_SECRET: ...
        APPLICATION_URL: ...
        APPLICATION_PORT: ...
        JWT_SECRET: ...
      },
    },
    publicLoadBalancer: ...
    redirectHTTP: ...
  });

I don’t believe AWS ALB exposes options to control buffering that I could add here, such as fastcgi_buffering and proxy_buffering, but let me know if I’m mistaken or if you think the problem might be caused by something else. Thank you for the help

To know if the issue come from buffering or cache, a very simple solution is to try to restart your server? Could you do it, or would you rather not because it’s your production server?

Hi Alban,

I’ve just restarted the production server and it seems to have fixed the issue. Thank you very much for your help! For my own understanding, why do you think this fixed the issue - I doubted it was a caching problem since the issue has existed since yesterday and I would have thought that any cached data would have been invalidated since then. Thanks again!

1 Like

When you restart the server, the cache is invalidated, and the agent retrieves all permissions via an HTTP GET request. While the server is running, permissions are fetched using Server-Sent Events (SSE) technology. This is why I recommend disabling buffering—reverse proxies sometimes cache events or parts of them, which can lead to faulty events if the buffer cuts the data. :confused: