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

[kainz]

• 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?

[tarelda]

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.

[TheTechArch]

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)

[XPlantefeve]

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.

[6543]

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