Gitea: [Question] How redirect to login instead of 404 for private repo?

[badstorm]

• 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

Screenshots

[zeripath]

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.

[badstorm]

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?

[lafriks]

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

[silverwind]

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.

[lafriks]

@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

[silverwind]

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.

[guillep2k]

@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.

[silverwind]

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

[lafriks]

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

[guillep2k]

@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.

[silverwind]

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.

[guillep2k]

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. 😵

[silverwind]

I guess one could introduce a semi-private option 🤣

[stale[bot]]

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]]

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