Change user hyper tag with UBID #1180
Conversation
enescakir
requested review from
fdr,
pykello,
byucesoy,
furkansahin and
velioglu
|
What happens when a name can't be resolved? It should error right? Maybe I missed the test for this (or it happens for free from the tests already existing?) |
If the name can't be resolved, nothing happen. The raw value is saved into policy not UBID value. |
Is that good? it means there's this odd blend of lazily bound names and eagerly bound names. What happens when a resource is introduced with that name later? Does it get then bound to a ubid whenever the policy happens to be edited and names re-resolved? This is basically a variant of lexical vs. dynamic scoping (version 2, electric boogaloo). We should pick one or actually support both like Common Lisp does (let's not support both is my default reflex, it sounds like we have more to gain from lexical scoping as it were) |
Earlier, I implemented `user_ids` method to retrieve the list of user ids associated with a project. This was during my early days. Now, we can use the Sequel method to obtain project users, which is more practical. This method is also beneficial for operational processes. I often found myself using `Account[project.user_ids.first]` to access the users.
When a field in a form fails validation, we display the error at the bottom of the relevant field. However, this requires the customer to scroll down, which can be inconvenient for long pages. To improve this, I've added a list of failed fields to the top of the page in the error view. This way, customers can quickly see the names of the fields that failed at a glance.
All resources are represented in our authorization system, referred to as a "hyper tag". Each resource has a unique format, for example, users are represented as "user/test@example.com", projects as "project/pjbw1tcvkew67qcxqsjpbvh19c", and virtual machines as "project/pjcm807azyxe6ht7ct027tcg83/location/hetzner-fsn1/vm/my-vm". We prefer using user-friendly names over UBIDs, making it easier for customers to edit their access policies. However, we identified a problem with this approach. When a resource's hyper tag changes (e.g., a user changes their email), the existing access policies need to be updated accordingly. Without such updates, permissions to resources could be affected. Automatically updating access policies to apply these changes is not recommended. Instead, I propose keeping the resource's UBID as the hyper tag in the database, which eliminates the need for changes when resources are renamed. This is because UBIDs remain constant throughout a resource's lifetime. We only need to map the prettified policy name when displaying or saving access policies. The authorization system uses UBIDs in the background. I have refactored the user's hyper tag for now. I will continue to refactor other resources in subsequent PRs after the deployment of user change. If the user is missing, it raises an error. We need to update user hyper tags in production after deployment. From a security perspective, we only transform tags/UBIDs for resources associated with this project.
enescakir
force-pushed
the
hyper-tag-ubid
branch
from
a52da99
to
b99ab31
Compare
|
I added a check for user existence. |
All resources are represented in our authorization system, referred to as a "hyper tag". Each resource has a unique format, for example, users are represented as
user/test@example.com, projects asproject/pjbw1tcvkew67qcxqsjpbvh19c, and virtual machines asproject/pjcm807azyxe6ht7ct027tcg83/location/hetzner-fsn1/vm/my-vm.We prefer using user-friendly names over UBIDs, making it easier for customers to edit their access policies. However, we identified a problem with this approach. When a resource's hyper tag changes (e.g., a user changes their email), the existing access policies need to be updated accordingly. Without such updates, permissions to resources could be affected.
Automatically updating access policies to apply these changes is not recommended. Instead, I propose keeping the resource's UBID as the hyper tag in the database, which eliminates the need for changes when resources are renamed. This is because UBIDs remain constant throughout a resource's lifetime.
We only need to map the prettified policy name when displaying or saving access policies. The authorization system uses UBIDs in the background.
I have refactored the user's hyper tag for now. I will continue to refactor other resources in subsequent PRs after the deployment of user change.
We need to update user hyper tags in production after deployment.
From a security perspective, we only transform tags/UBIDs for resources associated with this project.