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
Access Control: Clear user's permission cache after resource creation #59101
Conversation
Drone build failed: https://drone.grafana.net/grafana/grafana-enterprise/42817 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Drone build failed: https://drone.grafana.net/grafana/grafana-enterprise/42866 |
pkg/api/dashboard.go
Outdated
// Clear permission cache for the user who's created the dashboard, so that new permissions are fetched for their next call | ||
// Required for cases when caller wants to immediately interact with the newly created object | ||
if err := hs.accesscontrolService.ClearUserPermissionCache(c.SignedInUser); err != nil { | ||
return response.Error(500, "Failed to clear permission cache after dashboard creation", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think we should return a 500 here (some for the other endpoints). The only error we could get is that the signed in user is not something we can have in the cache and then there is nothing to clear anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, makes sense. Do you think we should just log a warning and continue on? Or just continue on without a warning?
@@ -26,6 +26,8 @@ type Service interface { | |||
registry.ProvidesUsageStats | |||
// GetUserPermissions returns user permissions with only action and scope fields set. | |||
GetUserPermissions(ctx context.Context, user *user.SignedInUser, options Options) ([]Permission, error) | |||
// ClearUserPermissionCache removes the permission cache entry for the given user | |||
ClearUserPermissionCache(user *user.SignedInUser) error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding my other comment, do we really need to return something here?
If the user can be cache we delete the associated key otherwise we just ignore it because it is not in the cache anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that makes sense. I'll remove the returned error.
Drone build failed: https://drone.grafana.net/grafana/grafana-enterprise/43166 |
@@ -470,14 +470,20 @@ func (hs *HTTPServer) postDashboard(c *models.ReqContext, cmd models.SaveDashboa | |||
} | |||
|
|||
if liveerr != nil { | |||
hs.log.Warn("unable to broadcast save event", "uid", dashboard.Uid, "error", err) | |||
hs.log.Warn("unable to broadcast save event", "uid", dashboard.Uid, "error", liveerr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to ignore this comment.
I really don't like this variable name, since it reminds me of the human organ liver
rather than and error from live
.
hs.log.Warn("unable to broadcast save event", "uid", dashboard.Uid, "error", liveerr) | |
hs.log.Warn("unable to broadcast save event", "uid", dashboard.Uid, "error", liveErr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha, that's pretty funny :) I'll leave it as it is for now, as I didn't introduce this error variable and don't want to add too many changes to this PR. But I'll keep it in mind for later.
Hello @IevaVasiljeva!
Please, if the current pull request addresses a bug fix, label it with the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.0.x origin/v9.0.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.0.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.0.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.1.x origin/v9.1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.1.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.1.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.2.x origin/v9.2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.2.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.2.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.0.x origin/v9.0.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.0.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.0.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.1.x origin/v9.1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.1.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.1.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.2.x origin/v9.2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.2.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.2.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.3.x origin/v9.3.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.3.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.3.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.2.x origin/v9.2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.2.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.2.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-59101-to-v9.3.x origin/v9.3.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x a8bae3f0b0cfc376a1d9698c364aa2e8abe7b71e
# Push it to GitHub
git push --set-upstream origin backport-59101-to-v9.3.x
git switch main
# Remove the local backport branch
git branch -D backport-59101-to-v9.3.x Then, create a pull request where the |
… creation (#59307) Access Control: Clear user's permission cache after resource creation (#59101) * refresh user's permission cache after resource creation * clear the cache instead of reloading the permissions * don't error if can't clear cache * fix tests * fix tests again (cherry picked from commit a8bae3f) Co-authored-by: Ieva <ieva.vasiljeva@grafana.com>
… creation (grafana#59307) Access Control: Clear user's permission cache after resource creation (grafana#59101) * refresh user's permission cache after resource creation * clear the cache instead of reloading the permissions * don't error if can't clear cache * fix tests * fix tests again (cherry picked from commit a8bae3f) Co-authored-by: Ieva <ieva.vasiljeva@grafana.com>
What is this feature?
Automatically reload user's permission cache after they create a folder, dashboard, team or a data source.
Why do we need this feature?
This would allow the creator to immediately access the created resource, which is needed by provisioning (Terraform etc), frontend etc.
Who is this feature for?
All users.
Which issue(s) does this PR fix?:
Related to grafana/terraform-provider-grafana#521 and grafana/terraform-provider-grafana#665
Special notes for your reviewer:
Another approach would be to call a separate endpoint to reload the permission cache (this is what we currently do from the frontend by calling
/api/access-control/user/actions?reloadcache=true
). However, I feel like automatically reloading the cache from the API handlers is a simpler solution and covers all the use cases (ie, other potential provisioning tools, custom scripts etc).