New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Table Permissions Doesn't Seem To Be Working With Embedded Select Statement #3985
Comments
Hi @ReziaBanks! Thank you for taking the time to write a detailed report for this issue you are experiencing. I will try to reproduce your scenario whenever I have a moment. For the time being, may I ask why not use |
I'm using Auth0 as my Authentication Provider, therefore the
|
Got it! I missed that detail when reading the issue. I understand you approach. You are relying on the permissions clause for Unfortunately, the current behavior in SurrealDB (#2161) leads to permissions clauses being able to read any data, causing your statement to simply return the first user record instead of the record belonging to the authenticated user. We are discussing this behavior as well as some related bugs in the context of a security issue in Thank you again for reporting this, I will keep this issue open and update it when this is resolved. For the time being, a potential alternative could be to use another unique user identifier already present on the token (e.g. For future reference, here is a simplified scenario that reproduces this issue: USE NS test DB test;
DEFINE TABLE user PERMISSIONS FOR SELECT WHERE name = $auth.name;
DEFINE TABLE post PERMISSIONS FOR SELECT WHERE user = (SELECT id FROM ONLY user LIMIT 1).id;
CREATE user:a CONTENT {"name": "a"};
CREATE user:b CONTENT {"name": "b"};
CREATE post:a CONTENT {"user": user:a};
CREATE post:b CONTENT {"user": user:b};
DEFINE SCOPE user
SESSION 1d
SIGNIN (SELECT * FROM user WHERE name = $name)
SIGNUP (CREATE user CONTENT {"name": $name})
; Then, I sign in as SELECT * FROM post;
[
{
id: post:a,
user: user:a
}
] I get the correct post for that user, great! SELECT * FROM post;
[
{
id: post:a,
user: user:a
}
] I get the same post. It seems that the CREATE user:1 CONTENT {"name": 1};
[[{ id: user:1, name: 1 }]]
CREATE post:1 CONTENT {"user": user:1};
[[{ id: post:1, user: user:1 }]] If our hypothesis is correct, selecting posts as any scope user should now return the post of SELECT * FROM post;
[
{
id: post:1,
user: user:1
}
] We sign in again as SELECT * FROM post;
[
{
id: post:1,
user: user:1
}
] It seems that our hypothesis is correct. The permissions clause has access to all users and will always return the first one. |
Thanks for the breakdown, adding a WHERE clause to the CURRENT USER function solved the issue. I think it would be helpful to add context (doesn't use scope permission in a scoped connection) on PERMISSIONS in the documentation. |
I agree that this behavior should be documented. Since we are currently in the process of redefining exactly how we want Thank you again for opening this issue! |
Describe the bug
I'm encountering an issue while configuring security rules for the
like
table in my database, which consists of three tables:user
,post
, andlike
. My goal is to restrict the creation and deletion of likes to the user who created them, utilizing Auth0 for authentication.To achieve this, I've set up a function that retrieves the current user by fetching the first user from the
user
table. Theuser
table contains permissions that are determined based on data retrieved from$token
.In defining the
like
table, I've specified aFOR CREATE, UPDATE
statement with aWHERE
clause, intending to restrict access to the creator of the like usingfn::current::user::id()
, representing the current user's ID. However, this logic doesn't seem to function as expected, and I'm uncertain about the reason behind it.As part of troubleshooting, I attempted to directly pass the user record instead of
fn::current::user::id()
, which seemed to resolve the issue. This led me to conclude that theWHERE
statement in the permission configuration does not accept an embeddedSELECT
statement.For instance, when I replaced the condition with
FOR CREATE WHERE in = (SELECT VALUE id FROM ONLY user LIMIT 1)
, the security rule failed to function as intended.Steps to reproduce
Expected behaviour
The
RELATE (fn::current::user::id())->like->post:7831
statement should run successfully.SurrealDB version
1.4.2
Contact Details
[email protected]
Is there an existing issue for this?
Code of Conduct
The text was updated successfully, but these errors were encountered: