-
Notifications
You must be signed in to change notification settings - Fork 81
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
Conversation
08909dd
to
a58d873
Compare
a58d873
to
e3ba1e9
Compare
disabled={!isAdmin} | ||
upVoted={isUpVoted} | ||
onClick={() => upVoteDataset(dataset.datasetUri)} | ||
upVotes={upVotes} | ||
/> |
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.
does UpVote
take in a disabled
prop / does this really do anything?
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.
It just shows the number of votes, it allows users to read the upVotes but not to upvote
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.
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
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.
…-permissions # Conflicts: # backend/dataall/modules/redshift_datasets/__init__.py
### 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.
- 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.
Feature or 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:
In this PR we mimic these 2 rules also in the backend:
GET_X
permissions to the resourceTesting
Relates
Security
Please answer the questions below briefly where applicable, or write
N/A
. Based onOWASP 10.
fetching data from storage outside the application (e.g. a database, an S3 bucket)?
eval
or similar functions are used?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.