-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
DISABLE_ACCESS_TOKENS parameter for disabling access tokens added #18488
base: main
Are you sure you want to change the base?
Conversation
Access tokens are hardcoded and cannot be disabled (i.e. when owner doesn't want this kind of authentication). This mod introduces new DISABLE_ACCESS_TOKENS parameter in app.ini section [security]. When disabled (default when parameter is not present) gitea behaves as without this mod (access tokens feature is available). When enabled, access tokens feature and its UI elements are not avaiable. This mod also hides those areas on Settings/Applications page that are disabled in config and hides menu link to Applications page if all its areas are disabled in config. Related: go-gitea#13129 Author-Change-Id: IB#1115254
Fixes: 2bde83b Author-Change-Id: IB#1115254
What is your potential reasoning and use-case for wanting to have these disabled? Realistically, almost no one will want to have it disabled as it breaks integration of almost any external service (including all CI/CD). I find it doubtful anyone would intentionally want to gut their instance that way. In addition, this breaks the desired use-case of tokens instead of username/password combination for Basic Auth for Git operations. |
"DisableAccessTokens": func() bool { | ||
return setting.DisableAccessTokens | ||
}, | ||
"DisableOAuth2": func() bool { |
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.
You don't mention anything about OAuth2 in this PR, what gives?
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.
What is your potential reasoning and use-case for wanting to have these disabled?
If someone want to disable some auth options (like tokens) - should be allowed to do it (i.e. for security reasons). Other stuff like OAuth2 has switches.
Realistically, almost no one will want to have it disabled as it breaks integration of almost any external service (including all CI/CD)
Think of systems that are isolated from all other apps and allows only authenticated user access (i.e. for security reasons).
All optional stuff in gitea should have switch to disable it. Don't try to be smarter than app owner.
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 find your security argument not convincing, considering that token authentication is far more secure than username/password combination for Basic Auth. Can you elaborate exactly how disabling this brings improved security over users being forced to specify (and remember) their username/password combinations in Git clients?
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.
Can you elaborate exactly how disabling this brings improved security over users being forced to specify (and remember) their username/password combinations in Git clients?
Think of authentication with HTTP header using reverse proxy. In this scenario one may want to authenticate users ONLY with HTTP header from proxy and disable all other auth stuff (like ssh keys, passwords, basic auths and other shiny toys). Now its proxy job to make auth secure (SSO for example using secure auth methods).
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.
Git clients are already smart enough to use more advanced auth methods than username+password. Tokens should be left available as option of course if one needs it (i.e. external app that understands tokens only).
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.
Think of authentication with HTTP header using reverse proxy. In this scenario one may want to authenticate users ONLY with HTTP header from proxy and disable all other auth stuff (like ssh keys, passwords, basic auths and other shiny toys). Now its proxy job to make auth secure (SSO for example using secure auth methods).
Assuming that Gitea can authenticate Git requests this way it would be a valid scenario.
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.
It can.
I also think the reasons and scenarios are necessary. |
+1 for what @CirnoT has said. We will eventually remove user/pass from git clone and this would leave users without a way to clone via HTTPS. |
This PR is not about basic auth. It's about allowing system owner to decide if token auth will be available or not in their gitea instance. This PR does not change default gitea behaviour - tokens will be still available by default. All auth methods should be optional and system admin (not gitea dev) should choose what is appropriate for given system instance. Basic auth, reverse proxy, oauth... are optional now; after this mod tokens should be optional also. |
@techknowlogick @lunny I rest my case here. Gitea can authenticate HTTP requests via reverse proxy authentication (SSO, etc.) so in this scenario tokens can be disabled and user would still not be forced to use username/password authentication (ie. they would authenticate Git credentials with their SSO provider which would pass proper authorization to Gitea). |
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.
While this PR does hide the UI and ability to modify tokens, it does not disable authentication with existing ones which is a major oversight.
@@ -372,6 +372,9 @@ INTERNAL_TOKEN= | |||
;; Set to true to disable webhooks feature. | |||
;DISABLE_WEBHOOKS = false | |||
;; | |||
;; Set to false to disable access tokens feature. |
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'd add a comment here that it should be changed only if using some kind of SSO and that it might break existing integrations.
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'd add a comment here that it should be changed only if using some kind of SSO and that it might break existing integrations.
If someone is touching such settings, should test it before in nonprod env. Describing all possible scenarios here (like SSO/noSSO, only basic auth without tokens, etc.) does not make sense IHMO.
Fixed in 3de67bf. |
When DISABLE_ACCESS_TOKENS=true, existing access tokens should be disabled. Fixes: 2bde83b Related: go-gitea#18488 (review) Author-Change-Id: IB#1115254
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions. |
access token should not be disabled except disabled API |
Is there a consensus that this functionality is not wanted? Then we should close this PR |
Access tokens are hardcoded and cannot be disabled (i.e. when
owner doesn't want this kind of authentication).
This mod introduces new DISABLE_ACCESS_TOKENS parameter in app.ini
section [security]. When disabled (default when parameter is not
present) gitea behaves as without this mod (access tokens feature
is available). When enabled, access tokens feature and its UI
elements are not avaiable.
This mod also hides those areas on Settings/Applications page
that are disabled in config and hides menu link to Applications
page if all its areas are disabled in config.
Related: #13129
Author-Change-Id: IB#1115254