api/v1/users/[:user]/tokens is too special. Make it less special? #1975

New Issue

GiteaMirror · 2025-11-02T04:19:55-06:00

GiteaMirror commented

2025-11-02 04:19:55 -06:00

Originally created by @kainz on GitHub (Jun 25, 2018).

Gitea version (or commit ref): v1.4.2, master
Git version: N/A
Operating system: Linux
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- [ X ] Not relevant
Log gist:

Description

If you are using gitea with any auth which disables basic user/pw login, the tokens API is effectively disabled. This breaks drone (and other token-handling) integrations if you are using anything but direct username/pw auth. See at least #2743, and #3843.

As is mentioned in #3843, the implementation of /tokens uses a couple hacks to minimize its logic, it only allows usage if a the call is authenticated through BasicAuth, and it also ignores the :user argument, only accessing tokens for the authenticated user.

If you are trying to build a system around gitea using any external login provider, this pretty much breaks all integrations.

A longer term fix for this sort of setup is probably having a full oauth consumer / ask for permissons workflow etc, but as a shorter term fix, I propose implementing the following:

Provide a configuration option to allow admin users to edit (add/remove) other users' tokens.
Provide a configuration option to toggle between the current 'safe?' behavior of the current tokens API, or allow the tokens API to be used from other login sources.

Related to these, there's another question to answer I think: in the presence of a token vs alternate auth (reverse proxy web header, oauth bearer etc), should the priority of those be configurable? Does it matter? Is there a long term authentication roadmap for Gitea?

I have the beginnings of a fix for number 2 here that I need to use Drone in my current org's setup (Mutual TLS auth everywhere), and think I have a good idea for basically doing 1, but I want to float the idea of mergability of these features.

Thoughts?

Originally created by @kainz on GitHub (Jun 25, 2018).  - Gitea version (or commit ref): v1.4.2, master - Git version: N/A - Operating system: Linux - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ X ] Not relevant - Log gist: ## Description If you are using gitea with any auth which disables basic user/pw login, the tokens API is effectively disabled. This breaks drone (and other token-handling) integrations if you are using anything but direct username/pw auth. See at least #2743, and #3843. As is mentioned in #3843, the implementation of `/tokens` uses a couple hacks to minimize its logic, it only allows usage if a the call is authenticated through BasicAuth, and it also ignores the `:user` argument, only accessing tokens for the authenticated user. If you are trying to build a system around gitea using any external login provider, this pretty much breaks all integrations. A longer term fix for this sort of setup is probably having a full oauth consumer / ask for permissons workflow etc, but as a shorter term fix, I propose implementing the following: 1. Provide a configuration option to allow admin users to edit (add/remove) other users' tokens. 2. Provide a configuration option to toggle between the current 'safe?' behavior of the current tokens API, or allow the tokens API to be used from other login sources. Related to these, there's another question to answer I think: in the presence of a token vs alternate auth (reverse proxy web header, oauth bearer etc), should the priority of those be configurable? Does it matter? Is there a long term authentication roadmap for Gitea? I have the beginnings of a fix for number 2 here that I need to use Drone in my current org's setup (Mutual TLS auth everywhere), and think I have a good idea for basically doing 1, but I want to float the idea of mergability of these features. Thoughts?

GiteaMirror added the type/proposal modifies/api labels 2025-11-02 04:19:55 -06:00

GiteaMirror closed this issue

2025-11-02 04:19:55 -06:00

GiteaMirror commented

2025-11-02 04:19:56 -06:00

@tarelda commented on GitHub (Jun 26, 2018):

I think it should be done with #27 and build around it.
Btw as I suggested in #4288 auth module is currently pile of garbage that needs major refactor and separation of concerns.

@tarelda commented on GitHub (Jun 26, 2018): I think it should be done with #27 and build around it. Btw as I suggested in #4288 auth module is currently pile of garbage that needs major refactor and separation of concerns.

GiteaMirror commented

2025-11-02 04:19:56 -06:00

@TheTechArch commented on GitHub (Jul 3, 2018):

We have the same need. Trying to integrate another plattform we are now forced to ask the user to generate token in GUI so we can store in other part of application. We want to generate tokens based on logged inn users session. (same as the other apis)

@TheTechArch commented on GitHub (Jul 3, 2018): We have the same need. Trying to integrate another plattform we are now forced to ask the user to generate token in GUI so we can store in other part of application. We want to generate tokens based on logged inn users session. (same as the other apis)

GiteaMirror commented

2025-11-02 04:19:56 -06:00

@XPlantefeve commented on GitHub (Mar 6, 2019):

I had a similar need (token creation automation) and after a few tests, I noticed that it can be done through the API with an administrator using basic authentication and sudoing as the user.

Obviously, it raises other issues (the admin user password has to be stored), but I plan to work around that block by setting a cron to watch users creation and create tokens centrally.

@XPlantefeve commented on GitHub (Mar 6, 2019): I had a similar need (token creation automation) and after a few tests, I noticed that it can be done through the API with an administrator using basic authentication and sudoing as the user. Obviously, it raises other issues (the admin user password has to be stored), but I plan to work around that block by setting a cron to watch users creation and create tokens centrally.

GiteaMirror commented

2025-11-02 04:19:56 -06:00

@6543 commented on GitHub (Sep 21, 2020):

token created by token is not the best way ...
if we have a right system to create token with different rights we can do this.

for now BasicAuth either via Admin or user credentials itselve has to be used

I'll close this issue since it is very old and if there is a specific problem a issue who describe it more exact should be created

@6543 commented on GitHub (Sep 21, 2020): token created by token is not the best way ... if we have a right system to create token with different rights we can do this. for now BasicAuth either via Admin or user credentials itselve has to be used I'll close this issue since it is very old and if there is a specific problem a issue who describe it more exact should be created

GiteaMirror referenced this issue

2025-11-02 12:03:31 -06:00

[PR #1975] [CLOSED] Issue #1957 - Fix forwarding stdin to pre/post-receive scripts #16154

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1975