I created a new User Account on Forest with team Operations and role USER
I modified Operations Collection permissions in order to disable create/update/delete for a certain table (a table that materialises a many-to-many relationship)
If I login with that User on Forest :
I can’t access production data → I get a forbidden error (although Operations can also normally access to production data)
I can still perform destructive operations on that table through this user on Forest
Feature(s) impacted
Roles management
Observed behavior
Roles management, configured on Forest Admin UI, does not seem to restrict my newly created user permissions.
Expected behavior
The new user should correctly see and operate on Production data, according to the collections permissions matrix I configured on Forest
The new user should not be able to perform create/update/delete on the table I mentioned, as configured in Forest Admin UI
Failure Logs
Forbidden Error 403
Context
Project name: Lift - Web App
Team name: Operations
Environment name: staging and Production
Database type: postgresql
Recent changes made on your end if any: none
And, if you are self-hosting your agent:
Agent technology: nodejs
Agent (forest package) name & version (from your .lock file): @forestadmin/agent: 1.55.1
I suspect that this issue is caused by some reverse proxy that could buffer SSE. As tackled by this troubleshooting section in our documentation.
From our side I can see that your agent is on version 1.64.1, which should notify you in the agent logs if it detects event buffering like so:
Unable to detect ServerSentEvents Heartbeat.
Forest Admin uses ServerSentEvents to ensure that permission cache is up to date.
It seems that your agent does not receive events from our server, this may due to buffering of events from your networking infrastructure (reverse proxy).
To ensure that this issue is caused by out of date permission cache on your agent, you can try to restart it and reenact the CRUD operation.
It may look like it was a caching issue indeed, since I can now see production data.
Although, the permission I set are still not operational on the UI.
What am I expected to see on the UI if I disable :
create
update
delete
CRUDS from a table ?
I did not see any SSE related logs on the backend side nor on the forest admin agent one.
Is there a way to enable verbose logging on Forest admin agent ?
Disable the SSE mechanism and fallback to old TTL cache by setting instantCacheRefresh: false in your agent init options.
what are the implications for disabling the SSE as the docs mention ? What’s the value for the TTL cache in that case ?
Further hints otherwise ?
My newly created user can still perform the operations I normally forbid from Forest UI on the specified database table.
I do not see a role “USER” in your project.
Only a role named “Operations” exists.
The last user “an**ss” created on your project on 10th June has the role “Operations”
Disabling write permissions results in having read permission only. The UI should work with it.
Disabling SSE will make forest servers won’t inform anymore your agent when permissions changed. It results a polling mechanism with a TTL on the cached permission on 10 seconds.
I updated the role permissions in order to disable creation and update on UserAccessOrganizations table
Then I see that users can also have different “permission levels” (ADMIN, USER, MANAGER …) → I tried to play with this different levels as well
The last user I created, the one with uses an email alias that ends with +testforest@gmail.com can still update or create entries in that table.
Disabling SSE will make forest servers won’t inform anymore your agent when permissions changed. It results a polling mechanism with a TTL on the cached permission on 10 seconds.
So disabling SSE does not look like being the right solution.
This issue is slowing down our development roadmap. Is it possible to have a direct slack contact or to organise a video call in order to rapidly solve this issue ?
What are your availabilities for a call ? I am available right now if you also are, if not I have sent you a private message on which you can schedule a call in my calendar.