Skip to content

Add shared route #26410

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

Open
JakobDev opened this issue Aug 9, 2023 · 0 comments
Open

Add shared route #26410

JakobDev opened this issue Aug 9, 2023 · 0 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@JakobDev
Copy link
Contributor

JakobDev commented Aug 9, 2023

Feature Description

For reference: This idea came up in the discussion of #26175

Gitea currently have 2 main routes: The API route and the Web route. Both have completely different authentication. If you are logged in on the Web route, you can't use the API to get your private repos. If you are using an API toke, you can't visit your private repos on the Web route.

That's fine in most cases, as both routes are for different things. But there are exceptions: Take for example release downloads. Both Web and API users might be interested to do this. But if these files belongs to a private repo, you need a authentication.

A solution that comes in mind would be to add these things to both routes. So you will have a download URL in the Web route that people get through the UI and you have a different download URL that will be returned by the API and that programs can use to download files with API authentication.

So everything is working now. Problem solved. Right? No! Let's imagine the following situation: You are a developer that uses Gitea and you have a popular Program that you offer to download for free. You also have some sort of getting Donations e.g. Patreon. To give your donors a little bonus , you offer them weekly Snapshots, that are not public, to try it out and give you feedback. The Snapshots are published on a Repo on your Gitea instance. Donor get a Account on your Gitea instance with access to this Repo, so they can download the Snapshot. So everything is working fine at the Moment. Your donors use the Web route to log in and download the Snapshot. No API involved. But there's a catch: You also have a public Discord server. To advertise the befits for donors a little bit, you decide to write a bot that pots every week something like: If you are a donator, you can get the latest Snapshot under this Link. But where should the Bot get the URL? The Bot would normally use the API, but as written above, the API now only returns a URL that can be used with API authentication. So your donors can't use the Link, even if the are logged in in the Web interface.

How do we solve the Problem? A solution would be to let the API return the URL for the Web route and the URL for the API route. The downside is, that we need to do this for all things that could be interesting for both routes e.g. Release Assets, Tarballs, Git clone links, Avatars, Issue attachments etc.It would also confuse API Users, which URL should they use in which case. We currently already have the Problem that the API for release Assets returns a field that is called browser_download_url, but this filed contains the URL for the API route and not the URL that you would use in a Browser.

I think the best solution is to add a 3rd route. Let's call it shared route until we'll have a better name. This routes supports both, API and Web Auth. We can put everything that should be shared between the Web and the API route in this new route. This would solve all the problems I described above.

As a side note: We currently have /attachments/{uuid}. This is part of the Web route, but it also supports API auth. We could do that in theory for others things like Release assets too, but this would be confusing. Why does this URL supports API auth but the other don't even if both are part of the Web route. There are also plans for adding an API only mode in the future which disables the Web route, so we can't rely on that.

Screenshots

No response

@JakobDev JakobDev added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

1 participant