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

Votes consistent permissions #1724

Merged
merged 5 commits into from
Dec 4, 2024
Merged

Votes consistent permissions #1724

merged 5 commits into from
Dec 4, 2024

Conversation

dlpzx
Copy link
Contributor

@dlpzx dlpzx commented Nov 27, 2024

Feature or Bugfix

  • Feature
  • Bugfix

Detail

The Votes submodule is used by Dashboards, Datasets and Redshift_Datasets in the frontend. Although in Dashboards anyone can see and click "upvote" and in the other 2 modules it is restricted to admins of the resource only.

In this PR we consolidate one single behavior for Votes:

  • The UpVote button is visible by all users: any user can get the number of upvotes for a data asset
  • The UpVote button is visible but disabled for any user except for the resource admin team: only users with access to the resource can vote for it.

In this PR we mimic these 2 rules also in the backend:

  • the upVote API is restricted to users with GET_X permissions to the resource
  • the getVote and countVotes APIs are open to all users

Testing

  • Deployed to AWS
  • Redshift Dataset owner can upvote a dataset
  • Programmatically a non-owner receives an error message when executing upvote

Relates

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

  • Does this PR introduce or modify any input fields or queries - this includes
    fetching data from storage outside the application (e.g. a database, an S3 bucket)?
    • Is the input sanitized?
    • What precautions are you taking before deserializing the data you consume?
    • Is injection prevented by parametrizing queries?
    • Have you ensured no eval or similar functions are used?
  • Does this PR introduce any functionality or component that requires authorization?
    • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
    • Are you logging failed auth attempts?
  • Are you using or adding any cryptographic features?
    • Do you use a standard proven implementations?
    • Are the used keys controlled by the customer? Where are they stored?
  • Are you introducing any new policies/roles/users?
    • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@dlpzx dlpzx force-pushed the feat/votes-consistent-permissions branch from 08909dd to a58d873 Compare November 27, 2024 12:18
@dlpzx dlpzx force-pushed the feat/votes-consistent-permissions branch from a58d873 to e3ba1e9 Compare November 28, 2024 14:36
@dlpzx dlpzx marked this pull request as ready for review November 29, 2024 11:34
Comment on lines +270 to +274
disabled={!isAdmin}
upVoted={isUpVoted}
onClick={() => upVoteDataset(dataset.datasetUri)}
upVotes={upVotes}
/>
Copy link
Contributor

Choose a reason for hiding this comment

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

does UpVote take in a disabled prop / does this really do anything?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It just shows the number of votes, it allows users to read the upVotes but not to upvote

Copy link
Contributor

Choose a reason for hiding this comment

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

Pretty sure I was a user who had share access to the dataset and was still able to execute upVote - only being stopped on the server side

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed, thank you!
image

@dlpzx dlpzx requested a review from noah-paige December 4, 2024 14:39
dlpzx added 2 commits December 4, 2024 15:51
…-permissions

# Conflicts:
#	backend/dataall/modules/redshift_datasets/__init__.py
@dlpzx dlpzx merged commit 934e17d into main Dec 4, 2024
9 checks passed
@dlpzx dlpzx mentioned this pull request Dec 5, 2024
dlpzx added a commit that referenced this pull request Dec 5, 2024
### Feature or Bugfix
- Bugfix

### Detail
Tests to count votes from #1724 fail because the client2 has no
permissions to GET a dataset and cannot upvote it

### Relates
- #1724 

### Security
Please answer the questions below briefly where applicable, or write
`N/A`. Based on
[OWASP 10](https://owasp.org/Top10/en/).

- Does this PR introduce or modify any input fields or queries - this
includes
fetching data from storage outside the application (e.g. a database, an
S3 bucket)?
  - Is the input sanitized?
- What precautions are you taking before deserializing the data you
consume?
  - Is injection prevented by parametrizing queries?
  - Have you ensured no `eval` or similar functions are used?
- Does this PR introduce any functionality or component that requires
authorization?
- How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  - Are you logging failed auth attempts?
- Are you using or adding any cryptographic features?
  - Do you use a standard proven implementations?
  - Are the used keys controlled by the customer? Where are they stored?
- Are you introducing any new policies/roles/users?
  - Have you used the least-privilege principle? How?


By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
dlpzx added a commit that referenced this pull request Dec 9, 2024
- Feature
- Bugfix

The Votes submodule is used by Dashboards, Datasets and
Redshift_Datasets in the frontend. Although in Dashboards anyone can see
and click "upvote" and in the other 2 modules it is restricted to admins
of the resource only.

In this PR we consolidate one single behavior for Votes:
- The UpVote button is visible by all users: any user can get the number
of upvotes for a data asset
- The UpVote button is visible but disabled for any user except for the
resource admin team: only users with access to the resource can vote for
it.

In this PR we mimic these 2 rules also in the backend:
- the upVote API is restricted to users with `GET_X` permissions to the
resource
- the getVote and countVotes APIs are open to all users

- [X] Deployed to AWS
- [X] Redshift Dataset owner can upvote a dataset
- [X] Programmatically a non-owner receives an error message when
executing upvote

Please answer the questions below briefly where applicable, or write
`N/A`. Based on
[OWASP 10](https://owasp.org/Top10/en/).

- Does this PR introduce or modify any input fields or queries - this
includes
fetching data from storage outside the application (e.g. a database, an
S3 bucket)?
  - Is the input sanitized?
- What precautions are you taking before deserializing the data you
consume?
  - Is injection prevented by parametrizing queries?
  - Have you ensured no `eval` or similar functions are used?
- Does this PR introduce any functionality or component that requires
authorization?
- How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  - Are you logging failed auth attempts?
- Are you using or adding any cryptographic features?
  - Do you use a standard proven implementations?
  - Are the used keys controlled by the customer? Where are they stored?
- Are you introducing any new policies/roles/users?
  - Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
@dlpzx dlpzx mentioned this pull request Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants