-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
fix permission check for creating comment while mail #22524
Conversation
only creating comment on locked issue request write permission, for others, read permission is enough. Signed-off-by: a1012112796 <1012112796@qq.com>
@@ -71,11 +71,16 @@ func (h *ReplyHandler) Handle(ctx context.Context, content *MailContent, doer *u | |||
return err | |||
} | |||
|
|||
if !perm.CanWriteIssuesOrPulls(issue.IsPull) || issue.IsLocked && !doer.IsAdmin { | |||
if !perm.CanWriteIssuesOrPulls(issue.IsPull) && issue.IsLocked && !doer.IsAdmin { |
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.
I think the old code tried to do something like:
- Return nil if the doer cannot write
- Even if the doer can write, return nil if the issue is locked and the doer is not admin.
So maybe we could just change it to:
if !perm.CanReadIssuesOrPulls(issue.IsPull) || issue.IsLocked && !doer.IsAdmin {
Edit:
So the old code is wrong.
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.
But with write permission, it could post comment even if issue.IsLocked from UI experience?
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.
but in the api, user with write permission can comment on locked issue. ref:
gitea/routers/api/v1/repo/issue_comment.go
Lines 360 to 363 in 9f919cf
if issue.IsLocked && !ctx.Repo.CanWriteIssuesOrPulls(issue.IsPull) && !ctx.Doer.IsAdmin { | |
ctx.Error(http.StatusForbidden, "CreateIssueComment", errors.New(ctx.Tr("repo.issues.comment_on_locked"))) | |
return | |
} |
if use your logic, they can't. I wonder ...
then use ||
and &&
but not use "(" is really hard to be understand for coder ...
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.
I see, could you please change it to if issue.IsLocked && ...
too? It does make it easier to understand.
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.
if !perm.CanWriteIssuesOrPulls(issue.IsPull) && issue.IsLocked && !doer.IsAdmin { | |
if issue.IsLocked && !perm.CanWriteIssuesOrPulls(issue.IsPull) && !doer.IsAdmin { |
this way?
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.
if !perm.CanWriteIssuesOrPulls(issue.IsPull) && issue.IsLocked && !doer.IsAdmin { | |
// Locked issues require write permissions | |
if issue.IsLocked && !perm.CanWriteIssuesOrPulls(issue.IsPull) && !doer.IsAdmin { |
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.
Wait, is Read
really enough to Write
an issue comment?
I can see a lot of problems waiting for us, i.e. when we add private issues…
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.
Yes. If you have read permission of issue, you can create issue and post comments.
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.
As I said: That will certainly make implementing private issues (safely) a pain.
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.
As I said: That will certainly make implementing private issues (safely) a pain.
I think has been diffcult now ... , when implementing private issues. it's better to use a unique servcie fuction to create commnt for both web ui, api and incoming mail...
@KN4CK3R wonder why get a error when shutdown (tested by outlook) |
Is that correct? That does not sound good.
Hm, I have never seen this message. |
that's same with web ui and api, looks github has same logic also(tested by: a1012112796/test_repo#2 (comment)). |
If the "write check" does not do what I think it was doing, we need another check to see if the user has access to the repo. Otherwise an user could reply to an older mail belonging to a now private repo. |
↑ That's exactly what I mean, it produces a lot of problems. |
Co-authored-by: delvh <dev.lh@web.de>
make LG-TM work |
* giteaofficial/main: (42 commits) Link issue and pull requests status change in UI notifications directly to their event in the timelined view. (go-gitea#22627) fix permission check for creating comment while mail (go-gitea#22524) Fix error on account activation with wrong passwd (go-gitea#22609) Fixes accessibility of empty repository commit status (go-gitea#22632) Use `--index-url` in PyPi description (go-gitea#22620) Show migration validation error (go-gitea#22619) Allow issue templates to not render title (go-gitea#22589) Fix `delete_repo` in template (go-gitea#22606) set org visibility class to basic in header (go-gitea#22605) Add API endpoint to get latest release (go-gitea#21267) Add ARIA support for Fomantic UI checkboxes (go-gitea#22599) Webhooks: for issue close/reopen action, add commit ID that caused it (go-gitea#22583) Add templates to customize text when creating and migrating repositories Prevent duplicate labels when importing more than 99 (go-gitea#22591) Remove address from DCO (go-gitea#22595) Allow setting `redirect_to` cookie on OAuth login (go-gitea#22594) Project links should use parent link methods (go-gitea#22587) link update in README files (go-gitea#22582) Frontport 1.18.2 and 1.18.3 Changelogs (go-gitea#22580) Fix incorrect Redis URL snippets in the example app.ini (go-gitea#22573) ...
only creating comment on locked issue request write permission,
for others, read permission is enough.
related to #22056
/cc @KN4CK3R