Obfuscate issue email participants based on member role
What does this MR do and why?
Describe in detail what your merge request does and why.
Obfuscates the service_desk_reply_to
(aka external_author
) email address in the Service Desk issue list and issue detail when the current user is not signed in or has no sufficient role (reporter
) in the given project. Also obfuscates issue_email_participants
of the issue in the same way.
This is only visible to Service Desk issues in public projects where the confidentiality of a Service Desk issue has been turned off.
- Solves Redact or hide issue email participants based o... (#383448 - closed)
- Solves Redact Service Desk email address when viewed b... (#353544 - closed)
- Solves Not possible to hide requester's e-mail when ma... (#12243 - closed)
General notes to email obfuscation in GitLab
To this date we only use an obfuscated email address on the identity confirmation page (aka "we sent a verification code to OBFUSCATED_EMAIL"). This uses SessionHelpers
obfuscated_email
method. This method only changes existing characters to *
and thus allows to guess the real email address. E.g. see@me.com.uk
becomes se*@m*****.uk
.
After a discussion we came to the conclusion that it's best to artificially deform the email address and also obfuscate the TLD of the address. The proposed solution is a pattern that uses a fixed number of *
, so we cannot tell the real length of the address. E.g. see@me.com.uk
becomes se*****@m*****.u**
.
See this comment in the discussion for full context.
After this has been merged, you can access this functionality globally in GitLab backend with Gitlab::Utils::Email.obfuscated_email("see@me.com.uk", deform: true)
.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
The screenshots are only taken from a public project with SD issues that are not confidential. Here is why:
- Private projects won't be accessible unauthorized or without a role in the project.
- A confidential issue won't be accessible unauthorized or without at least Reporter role in the project.
SD issue list
Description | Before | After |
---|---|---|
unauthorized (change) | ![]() |
![]() |
no role in project (change) | ![]() |
![]() |
guest role (change) | ![]() |
![]() |
min. reporter role | ![]() |
![]() |
SD issue detail
Description | Before | After |
---|---|---|
unauthorized (change) | ![]() |
![]() |
no role in project (change) | ![]() |
![]() |
guest role (change) | ![]() |
![]() |
min. reporter role | ![]() |
![]() |
SD issue detail comment
Description | Before | After |
---|---|---|
unauthorized | ![]() |
![]() |
no role in project (change) | ![]() |
![]() |
guest role (change) | ![]() |
![]() |
min. reporter role | ![]() |
![]() |
BTW this also works for multiple issue email participants (did not update the image with the new obfuscation, this is just to showcase the general functionality with more than one participants):
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
- Add a Service Desk issue or update an issue
i = Project.find_by(name: "Flight").issues.last
i.service_desk_reply_to = "my@mail.com"
i.author = User.support_bot
i.confidential = false
i.save!
IssueEmailParticipant.create!(email: "my@mail.com", issue: i)
- Turn confidentiality off for the issue (if it's confidential)
- Use a public project or make the project public.
- Access GitLab unauthorized
- Access the Service Desk issue list and validate SD issue list behavior (by email is obfuscated)
- Access the issue's detail page and validate SD issue detail behavior (by email is obfuscated in header)
- See that you cannot add a comment to the issue
- Access GitLab with a user that does not have a role in the project/group
- Access the Service Desk issue list and validate SD issue list behavior (by email is obfuscated)
- Access the issue's detail page and validate SD issue detail behavior (by email is obfuscated in header)
- Yellow/orange hint box below comment editor shows obfuscated email.
- Access GitLab with a user that has at least reporter role in the project/group
- Access the Service Desk issue list and validate SD issue list behavior (by email fully readable)
- Access the issue's detail page and validate SD issue detail behavior (by email is fully readable in header)
- Yellow/orange hint box below comment editor shows fully readable email.
-
☕ take a sip
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.