Remove need for client-based authorization with Visual Review Tools
Problem to solve
We can simplify and remove complexity around visual review tool authorization by completely removing the need to pass identities back and forth between GitLab, the app under review, and the web browser of the user providing feedback. At the moment this creates security risk and is difficult to set up.
Intended users
Further details
This is part of the project &960 (closed). It is a followup to gitlab-ee#10761.
Some additional feedback from @sytses
- Sid: Anyone should be able to leave feedback, just like service desk. No need to link to GitLab account.
- Sid: Iterate through getting feedback first and then work on ironing out any security issues that might come up
Current state
The current state can be checked out at https://review-app-test.sarahghp.now.sh/
Proposal
Instead of passing credentials back and forth, feedback will provided through a generic endpoint. The reviewer's browser will use this endpoint to provide a comment to the merge request under review. The user should be able to provide a name in addition to the comment.
A side benefit of this proposal is that even users who do not have GitLab accounts can now be involved in the review process.
The input filed for MR is required so the comment can get back to the right place if it was not automatically populated through the script in the review app OR hard coded.
Flow
graph TD UOR(Open review app) IMI(Input merge request ID if needed) IF(Input feedback) IN(Optional input name or username, anonymous by default) SF(submit feedback) LTF(Link towards submitted feedback shown) UOR-->IMI IMI-->IF IF-->IN IN-->SF SF-->LTF
Prototype

State wireframes
Name | Mockup |
---|---|
Input merge request ID if needed | ![]() |
Input feedback (anonymous selected by default) | ![]() |
Input full name (skipped if feedback submitted anonymously) | ![]() |
Input submitted and posted | ![]() |
Modal
Instruction number 3 will be removed as it is no longer applicable.
Feedback comment posted
At the top of the comment we need to post if this is posted anonymously: This feedback has been posted anonymously
If not anonymous: This feedback has been posted by NAME (note that there is no guarantee this person is verified)
Permissions and Security
Documentation
Testing
What does success look like, and how can we measure that?
Acceptance Criteria
- The flow can be completed as outlined above
- The comment is posted back to the correct MR within 30 seconds of submit.
Success Metrics
Once the issue to track usage of the Visual Review Tool #ee-11944 is completed we will measure success by number of users who utilize Visual Review Tools week over week.
Links / references
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.