[Question] How redirect to login instead of 404 for private repo? #5392

New Issue

GiteaMirror · 2025-11-02T06:23:21-06:00

GiteaMirror commented

2025-11-02 06:23:21 -06:00

Originally created by @badstorm on GitHub (May 13, 2020).

Gitea version: 1.11.5
Git version: 1.14.2
Operating system: linux-amd64
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- [x ] Yes
- No
- Not relevant

Description

There is the possibility to redirect to login page or show a custom alert message instead of the 404 page in this two cases when i try to connect directly form a url of a private repo:

if I'm not logged in
my user not have permissions for that repo.

For example i create this repo on try.gitea

Screenshots

Originally created by @badstorm on GitHub (May 13, 2020). - Gitea version: 1.11.5 - Git version: 1.14.2 - Operating system: linux-amd64 - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x ] Yes - [ ] No - [ ] Not relevant ## Description There is the possibility to redirect to _login page_ or show a custom alert message instead of the _404 page_ in this two cases when i try to connect directly form a _url_ of a private repo: - if I'm not logged in - my user not have permissions for that repo. For example i create this repo on [try.gitea](https://try.gitea.io/badstorm/bds_private_rep) ## Screenshots ![Schermata 2020-05-13 alle 12 23 41](https://user-images.githubusercontent.com/230256/81801413-af3b3900-9514-11ea-8470-736b8b7f63a7.png) ![Schermata 2020-05-13 alle 12 24 08](https://user-images.githubusercontent.com/230256/81801415-b104fc80-9514-11ea-8616-d82f53773d4b.png)

GiteaMirror added the type/question issue/stale labels 2025-11-02 06:23:21 -06:00

GiteaMirror closed this issue

2025-11-02 06:23:21 -06:00

GiteaMirror commented

2025-11-02 06:23:22 -06:00

@zeripath commented on GitHub (May 13, 2020):

Create a custom status/404.tmpl template. You should be able to detect ``{{.IsSigned}}` and you could put a form in to login.

If you come up with something that looks good and is understandable then please feel free to push it back as a PR.

@zeripath commented on GitHub (May 13, 2020): Create a custom `status/404.tmpl` template. You should be able to detect ``{{.IsSigned}}` and you could put a form in to login. If you come up with something that looks good and is understandable then please feel free to push it back as a PR.

GiteaMirror commented

2025-11-02 06:23:22 -06:00

@badstorm commented on GitHub (May 13, 2020):

Thanks for your suggestion. I'll try to work on it.
There is a way to detect from the 404 template if the error was generated by a wrong url or for a private repo?

@badstorm commented on GitHub (May 13, 2020): Thanks for your suggestion. I'll try to work on it. There is a way to detect from the 404 template if the error was generated by a wrong url or for a private repo?

GiteaMirror commented

2025-11-02 06:23:22 -06:00

@lafriks commented on GitHub (May 13, 2020):

Detecting wrong url or private repo would not be desirable becouse of security concerns. I would recommend just redirecting to login always

@lafriks commented on GitHub (May 13, 2020): Detecting wrong url or private repo would not be desirable becouse of security concerns. I would recommend just redirecting to login always

GiteaMirror commented

2025-11-02 06:23:22 -06:00

@silverwind commented on GitHub (May 14, 2020):

How about an config option to emit the correct status codes 401 (when not signed in) or 403 (when no permissions), something like MASK_STATUS_CODES=false? I'd even lean to defaulting it to on and security-concerned people can still turn it off and have their (technically incorrect and confusing) 404.

@silverwind commented on GitHub (May 14, 2020): How about an config option to emit the correct status codes 401 (when not signed in) or 403 (when no permissions), something like `MASK_STATUS_CODES=false`? I'd even lean to defaulting it to on and security-concerned people can still turn it off and have their (technically incorrect and confusing) 404.

GiteaMirror commented

2025-11-02 06:23:23 -06:00

@lafriks commented on GitHub (May 14, 2020):

@silverwind I don't agree, every other platform does the same as we do currently. Github for example adds additional link below 404 description to Sign in page where you can click to login

@lafriks commented on GitHub (May 14, 2020): @silverwind I don't agree, every other platform does the same as we do currently. Github for example adds additional link below 404 description to Sign in page where you can click to login

GiteaMirror commented

2025-11-02 06:23:23 -06:00

@silverwind commented on GitHub (May 14, 2020):

It's a tradeoff between security (hiding a repo's existance) and usability (not confusing users with wrong messages), I think it should be the user's choice.

@silverwind commented on GitHub (May 14, 2020): It's a tradeoff between security (hiding a repo's existance) and usability (not confusing users with wrong messages), I think it should be the user's choice.

GiteaMirror commented

2025-11-02 06:23:23 -06:00

@guillep2k commented on GitHub (May 15, 2020):

@silverwind I agree (but that's potentially a lot of work!). The problem here is that Gitea has "two faces": one is a public service where people from all over the world could get in and collaborate; the other is a corporate service where users are strictly listed and probably doesn't even face the Internet. This duality creates a lot of conundrums where the solution for one is bad news for the other.

Gitea 2.0 should be refactored so settings are more manageable, and this kind of decision tree is easier to maintain.

@guillep2k commented on GitHub (May 15, 2020): @silverwind I agree (but that's potentially a lot of work!). The problem here is that Gitea has "two faces": one is a public service where people from all over the world could get in and collaborate; the other is a corporate service where users are strictly listed and probably doesn't even face the Internet. This duality creates a lot of conundrums where the solution for one is bad news for the other. Gitea 2.0 should be refactored so settings are more manageable, and this kind of decision tree is easier to maintain.

GiteaMirror commented

2025-11-02 06:23:24 -06:00

@silverwind commented on GitHub (May 15, 2020):

@guillep2k What I don't quite get it why would you want to respond differently whether a instance is private or public? Let's say we return proper 401,403,404 status codes, in which case would you want to return different ones for public/private?

@silverwind commented on GitHub (May 15, 2020): @guillep2k What I don't quite get it why would you want to respond differently whether a instance is private or public? Let's say we return proper 401,403,404 status codes, in which case would you want to return different ones for public/private?

GiteaMirror commented

2025-11-02 06:23:24 -06:00

@lafriks commented on GitHub (May 16, 2020):

It's a tradeoff between security (hiding a repo's existance) and usability (not confusing users with wrong messages), I think it should be the user's choice.

And imho all systems take such tradeoff in favor of security. Just look at github, gitlab or pretty much any other

@lafriks commented on GitHub (May 16, 2020): > It's a tradeoff between security (hiding a repo's existance) and usability (not confusing users with wrong messages), I think it should be the user's choice. And imho all systems take such tradeoff in favor of security. Just look at github, gitlab or pretty much any other

GiteaMirror commented

2025-11-02 06:23:24 -06:00

@guillep2k commented on GitHub (May 16, 2020):

@guillep2k What I don't quite get it why would you want to respond differently whether a instance is private or public? Let's say we return proper 401,403,404 status codes, in which case would you want to return different ones for public/private?

IMHO it's because when it's a public service (facing Internet), some people may have privacy concerns ("I don't want anybody to know that I'm working on a particular fork, or even that I am registered in that site"), but in a corporate environment the company can dictate the policies and might care more about confusing new users than about hiding the existence of a particular resource. I work in a small company and I'm unsure whether I should maintain separate teams, because everybody knows about everybody else and anybody might be assigned to any project; secrecy would be overly bureaucratic.

@guillep2k commented on GitHub (May 16, 2020): > > > @guillep2k What I don't quite get it why would you want to respond differently whether a instance is private or public? Let's say we return proper 401,403,404 status codes, in which case would you want to return different ones for public/private? IMHO it's because when it's a public service (facing Internet), some people may have _privacy_ concerns (_"I don't want anybody to know that I'm working on a particular fork, or even that I am registered in that site"_), but in a corporate environment the company can dictate the policies and might care more about confusing new users than about hiding the existence of a particular resource. I work in a small company and I'm unsure whether I should maintain separate teams, because everybody knows about everybody else and anybody might be assigned to any project; secrecy would be overly bureaucratic.

GiteaMirror commented

2025-11-02 06:23:24 -06:00

@silverwind commented on GitHub (May 19, 2020):

I guess a per-repo setting to mask existance might be perfect. That way, you can still properly hide your top-secret repos while returning proper status codes for less important/public ones.

@silverwind commented on GitHub (May 19, 2020): I guess a per-repo setting to mask existance might be perfect. That way, you can still properly hide your top-secret repos while returning proper status codes for less important/public ones.

GiteaMirror commented

2025-11-02 06:23:25 -06:00

@guillep2k commented on GitHub (May 20, 2020):

I guess a per-repo setting to mask existance might be perfect. That way, you can still properly hide your top-secret repos while returning proper status codes for less important/public ones.

@silverwind That exists already. Repository: public, private. But there's a lot of gray-area cases, like public repo but private organization, or public repo but only for logged in users, etc. 😵

@guillep2k commented on GitHub (May 20, 2020): > > > I guess a per-repo setting to mask existance might be perfect. That way, you can still properly hide your top-secret repos while returning proper status codes for less important/public ones. @silverwind That exists already. Repository: `public`, `private`. But there's a lot of gray-area cases, like public repo but private organization, or public repo but only for logged in users, etc. 😵

GiteaMirror commented

2025-11-02 06:23:25 -06:00

@silverwind commented on GitHub (May 20, 2020):

I guess one could introduce a semi-private option 🤣

@silverwind commented on GitHub (May 20, 2020): I guess one could introduce a `semi-private` option 🤣

GiteaMirror commented

2025-11-02 06:23:26 -06:00

@stale[bot] commented on GitHub (Jul 19, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Jul 19, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

2025-11-02 06:23:26 -06:00

@stale[bot] commented on GitHub (Aug 2, 2020):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Aug 2, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 15:43:38 -06:00

[PR #5392] [MERGED] Fix dependent issue searching when gitea is run in subpath #17779

GiteaMirror referenced this issue

2025-11-02 15:45:08 -06:00

[PR #5400] [MERGED] Fix dependent issue searching when gitea is run in subpath (#5392) #17783

Sign in to join this conversation.