https://linen.dev logo
Join Slack
Powered by
Hey team, quick clarification: In the Python SDK,...
# permit-saas
t
Hey team, quick clarification: In the Python SDK, 
permit.check()
expects a user_id as the subject, and evaluates permissions based on that user’s assigned roles/policies. Is there a supported way to directly check permissions for a role (e.g. 
"admin"
) without going through a user? Or should we always create a test user with that role when we want to validate role-based access? Thanks.
a
Hi @Thillai, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
Based on the Python SDK documentation, 
permit.check()
requires a user identifier as the first argument (1) . The function signature is:
Copy code
permitted = await permit.check("<mailto:john@smith.com|john@smith.com>", "create", "document")
The SDK is designed to check permissions for specific users, not roles directly . The check evaluates whether a particular user (identified by their unique key) can perform an action on a resource. The documentation doesn't show a method to directly check permissions for a role without a user context. Creating a test user with the desired role would be the standard approach to validate role-based permissions, as the authorization model evaluates permissions based on the roles assigned to specific users.
To learn more, see the sources I considered: [[1] Python Quickstart Async](https://docs.permit.io/sdk/python/quickstart-python)
a
Hey @Thillai , Looking at your question and will be back to you
t
Sure, Thanks Alon
a
+1 for being able to do this. It's helpful for cases where you need to handle unauthenticated users (give them some but not all access to resources)
o
Folks, this is a terrible idea and against best practices, with all due respect. Checking for "admin" means you're coupling your policy and code, your code is aware of the concept of an admin... What happens when you decide you change your policy and "admin" no longer exists? If you need this for tetsing purposes create a dummy user which represents the "admin" scenario or "guest" scenario , assign them the role (later might be replaced by attribute, relationship, etc.) and test against it.
For unauthenticated users, you should avoid the temptation of not assigning them any id, as this would make your audit logs worthless. And at least assign them guids (these would work well with session cookies) and create users for them (with a Guest role for example), so you can separate the actions of each in your audit logs
a
kk will look at taking this approach for unauthenticated users. Thanks for the tip.
💜 1
Open in Slack
PreviousNext
Powered by