Skip to content
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

fix(alerts): restrict list view and gamma perms #21765

Merged
merged 9 commits into from
Oct 15, 2022

Conversation

villebro
Copy link
Member

@villebro villebro commented Oct 11, 2022

SUMMARY

Currently Gamma users have read and write permissions for Alerts & Reports and menu access for "Alerts & Reports". However, since they don't have access to the "Manage" menu, they can't see the menu item. This means that they can actually access the list view if the URL is provided to them. In addition, the list view shows all entries in the report schedule, although users are only able to edit entries they own.

This PR does the following:

  • Removes "can read on ReportSchedule", "can write on ReportSchedule" and "Alerts & Report" permissions from Gamma users
  • Adds a new base filter to only show owned entries for users without the all_datasource_access perm
  • Adds tests to assert that admin, alpha and gamma users see the all entries in the list view (admin sees all, alpha sees all, gamma with extra perms only sees owned entries)
  • If the user doesn't have edit rights (=isn't owner or isn't Admin) do the following:
    • disable the toggle
    • remove trashcan
    • replace "Edit" + Pen icon with "View" + Binoculars icon
  • Adds an entry to UPDATING.md with instructions on how to give perms to Gamma users

AFTER

When an Alpha user enters the list view, non-owned objects will appear with the toggle disabled, no trashcan and the "Edit" + Pen replaced with "View" + Binoculars (note that I didn't change the modal by dsabling fields etc, as changing that is a slightly bigger effort):
image

When a regular Gamma user tries to access the Alerts & Reports list view with the direct URL, they get an "Access denied" error:
image

When a Gamma user with the read on ReportSchedule perm accesses the list view, they can only see their own entries in the list view, despite there being four entries in the report schedule (see the Before screenshot):
image

BEFORE

Previously the Gamma and Alpha user saw and were able to edit all users' entries, despite not being able to change them (here I'm trying to enable another user's alert as a Gamma user, which fails due to missing perms).
image

Previously Gamma users were able to access the list view if they knew the URL, despite not having menu access:
image

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags:
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

@codecov
Copy link

codecov bot commented Oct 11, 2022

Codecov Report

Merging #21765 (58c27ce) into master (df3b5a8) will decrease coverage by 0.16%.
The diff coverage is 85.71%.

❗ Current head 58c27ce differs from pull request most recent head c2761a3. Consider uploading reports for the commit c2761a3 to get more accurate results

@@            Coverage Diff             @@
##           master   #21765      +/-   ##
==========================================
- Coverage   66.85%   66.68%   -0.17%     
==========================================
  Files        1805     1805              
  Lines       69061    69071      +10     
  Branches     7369     7369              
==========================================
- Hits        46169    46062     -107     
- Misses      20995    21112     +117     
  Partials     1897     1897              
Flag Coverage Δ
hive ?
mysql 78.25% <91.30%> (+<0.01%) ⬆️
postgres 78.30% <91.30%> (-0.01%) ⬇️
presto ?
python 81.10% <91.30%> (-0.35%) ⬇️
sqlite 76.80% <91.30%> (+<0.01%) ⬆️
unit 51.06% <30.43%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
superset/security/manager.py 95.75% <ø> (ø)
...perset-frontend/src/views/CRUD/alert/AlertList.tsx 62.50% <60.00%> (ø)
superset/reports/commands/execute.py 91.98% <83.33%> (ø)
superset/reports/api.py 90.29% <100.00%> (+0.07%) ⬆️
superset/reports/dao.py 84.92% <100.00%> (+0.24%) ⬆️
superset/reports/filters.py 95.23% <100.00%> (+2.38%) ⬆️
superset/db_engines/hive.py 0.00% <0.00%> (-85.19%) ⬇️
superset/db_engine_specs/hive.py 71.14% <0.00%> (-16.21%) ⬇️
superset/db_engine_specs/presto.py 81.05% <0.00%> (-6.73%) ⬇️
superset/reports/commands/log_prune.py 85.71% <0.00%> (-3.58%) ⬇️
... and 8 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@@ -32,6 +32,8 @@ assists people when migrating to a new version.

### Breaking Changes

- [21765](https://github.com/apache/superset/pull/21765): Gamma users will no longer have read and write access to Alerts & Reports. To give Gamma users the ability to schedule alerts and reports like before, create an additional role with "can read on ReportSchedule", "can write on ReportSchedule", "menu access on Manage" and "menu access on Alerts & Report".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@villebro I wonder if someone were to read this entry without seeing your explanation in the PR, if they would think that they need to grant access to Gamma users to keep the same functionality that we have now. This is tricky, because to most people it won't look like a breaking change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point - I'll make the entry more explicit, specifically scoping this to deployments that have enabled the "ALERT_REPORTS" feature flag.

@eschutho
Copy link
Member

@villebro I asked for some product/design feedback on what an alpha can see on the list page, too.

@yousoph
Copy link
Member

yousoph commented Oct 13, 2022

hi @villebro !! I'm wondering if it might make sense for an Alpha user to see all Alerts & Reports in the list view, but with no actions in the actions column and a disabled "Active" toggle if they aren't the owner, like the bottom row here:
Frame 201
There could be a case where an Alpha user is a recipient of a report but not the owner, and not seeing it in the list view could be confusing or lead to duplicates being created unintentionally.

In the future, maybe there could be a "View Only" mode to see report details even if you can't edit (though that is probably out of the scope of this PR)

Open to feedback here though, what are your thoughts?

@villebro villebro force-pushed the villebro/gamma-perms branch 3 times, most recently from 3076df0 to a54b285 Compare October 13, 2022 06:27
Copy link
Member

@dpgaspar dpgaspar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

ReportScheduleStateMachine(
session, self._execution_id, self._model, self._scheduled_dttm
).run()
with override_user(_get_user()):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since this method always runs on a celery async context I see no issue here, but what are we trying to solve?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it for switching current user to the user = security_manager.find_user(username=app.config["THUMBNAIL_SELENIUM_USER"])

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zhaoyongjie yes it switches the user, just wondering why we need g.user set on async tasks, to set changed_by fields?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new BaseFilter checks sm.is_admin(), which in turn checks the roles of g.user, which otherwise will be unset. So without this change executing Alerts and Reports fails (the integration tests thankfully picked this up 👍 )

Copy link
Member

@zhaoyongjie zhaoyongjie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fixing. I have tested it in my local, it works as expected. leave some non-blocking suggestions for testing code style.

image

Comment on lines 56 to 92
def create_working_admin_report_schedule(self):
with self.create_app().app_context():

admin_user = self.get_user("admin")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one nit, in order to avoid extra indeed and context grammar, we should use app_context and login_admin fixtures

def create_working_report_schedule(app_context, login_admin):
    ....
    ....

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason I'm having trouble using these fixtures with the class-based tests. Let's leave this for a follow-up refactor PR when these tests are refactored into functional tests.

Comment on lines 80 to 84
@pytest.fixture()
def create_working_alpha_report_schedule(self):
with self.create_app().app_context():

alpha_user = self.get_user("alpha")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is a fixture called login_as might help for this case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

@villebro
Copy link
Member Author

hi @villebro !! I'm wondering if it might make sense for an Alpha user to see all Alerts & Reports in the list view, but with no actions in the actions column and a disabled "Active" toggle if they aren't the owner, like the bottom row here: Frame 201 There could be a case where an Alpha user is a recipient of a report but not the owner, and not seeing it in the list view could be confusing or lead to duplicates being created unintentionally.

In the future, maybe there could be a "View Only" mode to see report details even if you can't edit (though that is probably out of the scope of this PR)

Open to feedback here though, what are your thoughts?

I see where you're coming from, and I agree in the context of Alerts and Reports it could make sense to have elevated privileges for the Alpha role. However, in the current context, this would go against current RBAC conventions, as Alpha is only able to see owned Charts and Dashboards. Having different logic for what Alpha can see on Dashboards and Charts vs Alerts and Reports could be confusing. For this reason I'd almost propose starting a separate discussion about what Alpha should and should not be able to see, and then apply this consistently throughout all object types.

Ping @dpgaspar , do you have any thoughts on this topic?

@villebro
Copy link
Member Author

villebro commented Oct 13, 2022

hi @villebro !! I'm wondering if it might make sense for an Alpha user to see all Alerts & Reports in the list view, but with no actions in the actions column and a disabled "Active" toggle if they aren't the owner, like the bottom row here: Frame 201 There could be a case where an Alpha user is a recipient of a report but not the owner, and not seeing it in the list view could be confusing or lead to duplicates being created unintentionally.
In the future, maybe there could be a "View Only" mode to see report details even if you can't edit (though that is probably out of the scope of this PR)
Open to feedback here though, what are your thoughts?

I see where you're coming from, and I agree in the context of Alerts and Reports it could make sense to have elevated privileges for the Alpha role. However, in the current context, this would go against current RBAC conventions, as Alpha is only able to see owned Charts and Dashboards. Having different logic for what Alpha can see on Dashboards and Charts vs Alerts and Reports could be confusing. For this reason I'd almost propose starting a separate discussion about what Alpha should and should not be able to see, and then apply this consistently throughout all object types.

@yousoph I stand corrected - the Alpha role does indeed have the all_datasource_access, which gives the Alpha user full visibility into all dashboards, datasets and charts. I'm going to change this logic so that instead of checking is_admin, I'm going to check for all_datasource_access, and if that's the case, it will show all Alerts & Reports.

@villebro
Copy link
Member Author

@yousoph I've changed the frontend so that non-admins will have a slightly different UX depending on whether or not they are owners (see screenshots in description)

@villebro
Copy link
Member Author

/testenv up FEATURE_ALERT_REPORTS=true

@github-actions
Copy link
Contributor

@villebro Ephemeral environment spinning up at http://54.202.241.131:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

@yousoph
Copy link
Member

yousoph commented Oct 14, 2022

Thanks for the updates, this is looking great!!

One thing I noticed for the Alpha user - when they try to save changes on a report that they don't own, they see a toast with this message:
An error occurred while fetching reports: "Forbidden"

I think the buttons on the modal should be hidden (or disabled)... or if that's not doable we should at least update the toast message to clarify to the user why the save failed.

@villebro
Copy link
Member Author

Thanks for the updates, this is looking great!!

One thing I noticed for the Alpha user - when they try to save changes on a report that they don't own, they see a toast with this message:

An error occurred while fetching reports: "Forbidden"

I think the buttons on the modal should be hidden (or disabled)... or if that's not doable we should at least update the toast message to clarify to the user why the save failed.

I noticed the same (there's also an annoying pluralization on the model name, making it "Reportss" 😄 I checked that fixing these is slightly more work than I have time for now, but I'll try to find time to fix these in a follow up PR.

@villebro villebro merged commit 4c1777f into apache:master Oct 15, 2022
@github-actions
Copy link
Contributor

Ephemeral environment shutdown and build artifacts deleted.

@villebro villebro deleted the villebro/gamma-perms branch October 16, 2022 09:13
@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 2.1.0 and removed 🚢 2.1.3 labels Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels size/L 🚢 2.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants