Query History: Prevent viewers from accessing

[gelicia]

What is this feature?

This adds a permissions check to ensure a user attempting to access query history has access to do so.

Why do we need this feature?

There is an edge case where a user had, then lost access, but still can access their previously ran queries. Viewers should not have access to queries. In Query History, users can only access their own queries, so this is a low priority security issue.

Which issue(s) does this PR fix?:

Fixes #88722

Special notes for your reviewer:
Tested this with an editor, viewer, and viewer with

[users]
viewers_can_edit = true

Please check that:

• It works as expected from a user's perspective.
• If this is a pre-GA feature, it is behind a feature toggle.
• The docs are updated, and if this is a notable improvement, it's added to our What's New doc.

[ifrost]

I think we should also apply it to all query history endpoints 🤔

[diegommm]

Hi! Greetings from the Release Guild. Just letting you know I'm updating your PR's milestone to 11.2.x. If you need to see your changes in a previous version, please consider adding a backport label.

Thank you!

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 2 weeks if no further activity occurs. Please feel free to give a status update or ping for review. Thank you for your contributions!

[gelicia]

@ifrost I'm really sorry, I spaced on this one. I was asking the access team if they had anything for an exception for viewers_can_access and the outcome was a no. I thought about making a global auth middleware setting for this, but in the end I think it's a fairly unique scenario where trying to bake it into something core is overkill. I just added the same logic to every handler.

Why I think this is unique: Viewers can edit rides this line where people can run queries, but not save anything. Explore access is fully allowed, dashboard panels can be edited, but not saved. Query history a.) is an outcome of running queries (good!) b.) saves something to the database (bad!) so its kind of in-between. I do think we just want to save stuff to the database for viewers here, and if it ever becomes an issue we can change the frontend logic to only save query history data to local storage for viewers.

[ifrost]

@ifrost I'm really sorry, I spaced on this one. I was asking the access team if they had anything for an exception for viewers_can_access and the outcome was a no.

I feel like this should be implemented the same way as the access to Explore, i.e. the access being elevated when viewers_can_edit = true

• Explore uses ac.ActionDatasourcesExplore,
• which is additionally granted to the Viewer here
• and it's using fixed:datasources:explorer role

We can have a new permission for QueryHistory specifically that is available only to Editors (or Viewers when viewers_can_edit is enabled). Otherwise we end up in two ways of handling viewers_can_edit which will be hard to maintain.

But anyway - Dashboards to their own magic when handling viewer_can_edit anyway, so I'm happy to merge it as it as as well and create a follow-up ticket to refactor it 👍