Skip to content
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

Allow options to disable user gpg keys configuration from the interface on app.ini #29486

Merged
merged 2 commits into from
Mar 2, 2024

Conversation

lunny
Copy link
Member

@lunny lunny commented Feb 29, 2024

Follow #29447
Fix #29454
Extract from #20549

@lunny lunny added the type/enhancement An improvement of existing functionality label Feb 29, 2024
@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Feb 29, 2024
@pull-request-size pull-request-size bot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Feb 29, 2024
@github-actions github-actions bot added modifies/api This PR adds API routes or modifies them modifies/docs labels Feb 29, 2024
@lunny lunny changed the title Allow disable gpg keys Allow options to disable user gpg keys configuration from the interface on app.ini Feb 29, 2024
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Feb 29, 2024
@lunny lunny added this to the 1.22.0 milestone Feb 29, 2024
Comment on lines +136 to +139
if setting.Admin.UserDisabledFeatures.Contains(setting.UserFeatureManageGPGKeys) {
ctx.NotFound("Not Found", fmt.Errorf("gpg keys setting is not allowed to be visited"))
return
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we move this check into the middleware to keep the logic in the router on topic?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did that on #20549 but @wxiaoguang think it's better to move them into the router function body.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean this comment? #29275 (comment)

At that time:

  1. Only one handler needs such check
  2. It bloats the "web.go", do we really want to fill more and more function into "web.go"?

For this time: it is still the only way: put checks into routers/web/user/setting/keys.go, it is impossible to "move into middleware" for it.

My reviews never means "it must do so", I am always open for better ideas.

So, for this problem: what is the consistent and maintainable approach in your mind?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like this for the middleware:

func featureEnabled(feature /*...*/string) func(ctx *context.Context) {
	if setting.Admin.UserDisabledFeatures.Contains(feature) {
		ctx.Error(http.StatusNotFound)
		return
	}
}

But that does not work well with the method with the type parameter. Repeating the same code multiple times is not really good either.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And by the way, I think my concern for "testing" is still not addressed there #29275 (comment)

Copy link
Contributor

@wxiaoguang wxiaoguang Feb 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But that does not work well with the method with the type parameter. Repeating the same code multiple times is not really good either.

There is no consistent way at the moment (if there is no refactoring). You can see that there is no way to use your middleware for the "web.go" now.


Update: I didn't mean blocker, and I don't have other ideas besides "refactoring to a clearer approach".

So feel free to use any style people prefer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really no way but we need to use one unpleasant way.

@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Mar 2, 2024
@lafriks lafriks enabled auto-merge (squash) March 2, 2024 00:56
@lafriks lafriks merged commit 9de5e39 into go-gitea:main Mar 2, 2024
26 checks passed
@lunny lunny deleted the lunny/disable_gpg_keys branch March 2, 2024 08:37
zjjhot added a commit to zjjhot/gitea that referenced this pull request Mar 2, 2024
* giteaofficial/main:
  Actions Artifacts v4 backend (go-gitea#28965)
  Remove jQuery AJAX from common global functions (go-gitea#29528)
  Allow options to disable user gpg keys configuration from the interface on app.ini (go-gitea#29486)
  [skip ci] Updated translations via Crowdin
  Fix issue & comment history bugs (go-gitea#29525)
  Fix incorrect diff expander for deletion of last lines in a file (go-gitea#29501)
  Ignore `__debug_bin*` which is generated by vscode when debugging (go-gitea#29524)
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 10, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. modifies/api This PR adds API routes or modifies them modifies/docs size/M Denotes a PR that changes 30-99 lines, ignoring generated files. type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ability to Disable PGP/GPG Keys
6 participants