Logging out redirects to front page #11077

New Issue

2025-11-02T09:26:55-06:00

GiteaMirror commented

2025-11-02 09:26:55 -06:00

Originally created by @drsybren on GitHub (Jun 22, 2023).

Description

Logging out always redirects you to the front page.

Open https://try.gitea.io/drSybren/skyfill while not yet logged in. This shows that this URL is public.
Log in
See that you're still on https://try.gitea.io/drSybren/skyfill
Log out
Now you've been redirected to https://try.gitea.io/ even though there was no need to move away from the given URL.

Screenshots

This is about redirects, can't really be captured in a screenshot.

Gitea Version

1.20.0+dev-1026-ge29ab5442

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

No response

Browser Version

Brave 1.52.126

Originally created by @drsybren on GitHub (Jun 22, 2023). ### Description Logging out always redirects you to the front page. - Open https://try.gitea.io/drSybren/skyfill while not yet logged in. This shows that this URL is public. - Log in - See that you're still on https://try.gitea.io/drSybren/skyfill - Log out - Now you've been redirected to https://try.gitea.io/ even though there was no need to move away from the given URL. ### Screenshots This is about redirects, can't really be captured in a screenshot. ### Gitea Version 1.20.0+dev-1026-ge29ab5442 ### Can you reproduce the bug on the Gitea demo site? Yes ### Operating System _No response_ ### Browser Version Brave 1.52.126

GiteaMirror added the type/proposal topic/ui labels 2025-11-02 09:26:55 -06:00

GiteaMirror commented

2025-11-02 09:26:55 -06:00

@silverwind commented on GitHub (Jun 22, 2023):

It could be that the repo is private, in which case staying on the URL would result in a 404 error. I think that is the reason for the redirect.

Generally I think that the login page should not have its own URL and just be shown dynamically based on authentication need, avoiding the need for all related redirects, but I recall some people were against this behaviour.

@silverwind commented on GitHub (Jun 22, 2023): It could be that the repo is private, in which case staying on the URL would result in a 404 error. I think that is the reason for the redirect. Generally I think that the login page should not have its own URL and just be shown dynamically based on authentication need, avoiding the need for all related redirects, but I recall some people were against this behaviour.

GiteaMirror commented

2025-11-02 09:26:56 -06:00

@drsybren commented on GitHub (Jun 22, 2023):

It could be that the repo is private, in which case staying on the URL would result in a 404 error. I think that is the reason for the redirect.

That could very well be, but it's still annoying and unnecessary. And as I put in my report, this happens for non-private repositories as well.

Also a 404 would be the wrong code to indicate an access issue, and 403 Forbidden would be more appropriate. And for me it would be perfectly fine to see an "forbidden" message when I just logged out.

Generally I think that the login page should not have its own URL and just be shown dynamically based on authentication need, avoiding the need for all related redirects, but I recall some people were against this behaviour.

The redirects are fine, as long as they direct you to the appropriate place.

@drsybren commented on GitHub (Jun 22, 2023): > It could be that the repo is private, in which case staying on the URL would result in a 404 error. I think that is the reason for the redirect. That could very well be, but it's still annoying and unnecessary. And as I put in my report, this happens for non-private repositories as well. Also a 404 would be the wrong code to indicate an access issue, and 403 Forbidden would be more appropriate. And for me it would be perfectly fine to see an "forbidden" message when I just logged out. > Generally I think that the login page should not have its own URL and just be shown dynamically based on authentication need, avoiding the need for all related redirects, but I recall some people were against this behaviour. The redirects are fine, as long as they direct you to the appropriate place.

GiteaMirror commented

2025-11-02 09:26:56 -06:00

@delvh commented on GitHub (Jun 22, 2023):

Also a 404 would be the wrong code to indicate an access issue, and 403 Forbidden would be more appropriate. And for me it would be perfectly fine to see an "forbidden" message when I just logged out.

Unfortunately, that's not possible:
The 404 for that is deliberate for security reasons, otherwise you will always know if a repo doesn't exist or if you don't have permission to view it.

@delvh commented on GitHub (Jun 22, 2023): > Also a 404 would be the wrong code to indicate an access issue, and 403 Forbidden would be more appropriate. And for me it would be perfectly fine to see an "forbidden" message when I just logged out. Unfortunately, that's not possible: The 404 for that is deliberate for security reasons, otherwise you will always know if a repo doesn't exist or if you don't have permission to view it.

GiteaMirror commented

2025-11-02 09:26:56 -06:00

@drsybren commented on GitHub (Jun 22, 2023):

That reeks of security by obscurity, but this is not the place to discuss that.

Between the two login/logout/redirect-related issues I filed today (this one and #25435), #25435 is the more common one for me to be hindered by, though.

@drsybren commented on GitHub (Jun 22, 2023): That reeks of security by obscurity, but this is not the place to discuss that. Between the two login/logout/redirect-related issues I filed today (this one and #25435), #25435 is the more common one for me to be hindered by, though.

GiteaMirror commented

2025-11-02 09:26:56 -06:00

@silverwind commented on GitHub (Jun 22, 2023):

In any case, as already mentioned, I think the solution to this and https://github.com/go-gitea/gitea/issues/25435 is to just not alter existing URL path and query parameters when user clicks the login button.

E.g. user clicks the "Login" button, sends a ?login=true query to the current page URL, backend renders login page because it reacts on the login parameter and on success redirects to the same page path and query with the login query parameter removed.

That mechanism should be compatible with current standalone /user/login page, but I guess iedally the standalone login page should be removed completely and replaced by this login=true mechanism.

@silverwind commented on GitHub (Jun 22, 2023): In any case, as already mentioned, I think the solution to this and https://github.com/go-gitea/gitea/issues/25435 is to just not alter existing URL path and query parameters when user clicks the login button. E.g. user clicks the "Login" button, sends a `?login=true` query to the current page URL, backend renders login page because it reacts on the `login` parameter and on success redirects to the same page path and query with the `login` query parameter removed. That mechanism should be compatible with current standalone `/user/login` page, but I guess iedally the standalone login page should be removed completely and replaced by this `login=true` mechanism.

GiteaMirror commented

2025-11-02 09:26:56 -06:00

@puni9869 commented on GitHub (Jul 21, 2023):

Can we close this ISSUE if it is done.

@puni9869 commented on GitHub (Jul 21, 2023): Can we close this ISSUE if it is done.

GiteaMirror commented

2025-11-02 09:26:56 -06:00

@lunny commented on GitHub (Jul 21, 2023):

Can we close this ISSUE if it is done.

https://github.com/go-gitea/gitea/pull/25522#issuecomment-1607491968

@lunny commented on GitHub (Jul 21, 2023): > Can we close this ISSUE if it is done. https://github.com/go-gitea/gitea/pull/25522#issuecomment-1607491968

GiteaMirror commented

2025-11-02 09:26:57 -06:00

@lunny commented on GitHub (Mar 27, 2024):

I think this is a design problem rather than a bug.

@lunny commented on GitHub (Mar 27, 2024): I think this is a design problem rather than a bug.

GiteaMirror commented

2025-11-02 09:26:57 -06:00

@n1tehawk commented on GitHub (Apr 8, 2024):

Replying here, since #25522 is locked.

I'm also a bit unhappy with the change in that PR, as it looks like a bit of a regression to me. Why? Before that change, users had the opportunity to change the redirection URL via customization of templates/base/head_navbar.tmpl, namely the data-redirect="..." attribute in the link tag. After #25522 got applied, the destination is now always the AppSubURL (gitea "home page").

So while https://github.com/go-gitea/gitea/pull/25522#issuecomment-1607491968 might apply in theory

But after this PR, backend can have full control of the "redirect URL", so it's easy to change the "redirect behavior" to anything the users like in the future.

in reality there currently seems to be no real choice.

It matters to me because im using gitea for a private repo site in conjunction with "single sign-on" via NextCloud as an OAuth2 provider. In the past it was easy to customize the logout to return the users to the cloud dashboard / start page (where they would have a link to return to the code site if desired). But now they land on the gitea home page and have to navigate / find their way back to the cloud manually...

It would be nice if this logic could be changed / extended in a way that would allow to specify the destination URL again - either via some template attribute, or maybe some dedicated (app.ini) configuration setting.

Regards, NiteHawk

@n1tehawk commented on GitHub (Apr 8, 2024): Replying here, since #25522 is locked. I'm also a bit unhappy with the change in that PR, as it looks like a bit of a regression to me. Why? Before that change, users had the opportunity to change the redirection URL via customization of `templates/base/head_navbar.tmpl`, namely the `data-redirect="..."` attribute in the link tag. After #25522 got applied, the destination is now always the `AppSubURL` (gitea "home page"). So while https://github.com/go-gitea/gitea/pull/25522#issuecomment-1607491968 might apply in theory > But after this PR, backend can have full control of the "redirect URL", so it's easy to change the "redirect behavior" to anything the users like in the future. in reality there currently seems to be no real choice. It matters to me because im using gitea for a private repo site in conjunction with "single sign-on" via NextCloud as an OAuth2 provider. In the past it was easy to customize the logout to return the users to the cloud dashboard / start page (where they would have a link to return to the code site if desired). But now they land on the gitea home page and have to navigate / find their way back to the cloud manually... It would be nice if this logic could be changed / extended in a way that would allow to specify the destination URL again - either via some template attribute, or maybe some dedicated (_app.ini_) configuration setting. Regards, NiteHawk

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#11077