-
Notifications
You must be signed in to change notification settings - Fork 19
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
Verify requesting user view permission #41
Comments
It sounds like a great idea. I'm not sure how easy it is, but I'll have a look at it. |
okay. thanks |
The following REST call seems to accomplish this so I think there is a way forward: https://docs.atlassian.com/jira/REST/cloud/#api/2/user-findUsersWithBrowsePermission @eloo Just to clarify something: Doing this only really works if the user names in rocket-chat matches those in JIRA. I hope this is the case in your organization. |
@gustavkarlsson nice research done from your site. yeah normally the username is the email address of a user. this, i guess, applies to most companies. maybe this feature should be configurable (enable/disable) |
@eloo It should definitely be configurable (and disabled by default). However, I've been thinking more about security issues lately, and I'm weary of the false sense of security this gives users... If the JIRA setup contains issues that are hidden from some users, others that have the permission to view it might accidentally "expose" it merely by mentioning the issue key. This is already an issue if the "login user" if given access to limited visibility issues, but at least that can be managed by a security-aware admin. Maybe a better solution would be to only show issues that are visible to all users? |
@gustavkarlsson yeah we discussed this too but the requester should be aware of who is reading a message. because other may non-public content could also be shared by simply chatting around. |
You've got a point there. I'll have to document this behavior so that people understand the implications, but I think this is still probably the best solution to the problem. |
yes this must be documented. |
Relating to security and privacy it would be great if the requesting user could be verified that he is permitted to view the request issue.
If the user has access the issue should be posted otherwise nothing should happen.
Do you plan to implement such a security feature?
The text was updated successfully, but these errors were encountered: