fix: Fix to delete cookie when AppSubURL is non-empty

[jtran]

Problem

We were observing a redirect loop, either when logging out or when trying to view a private repo with an expired session. This only seems to happen when AppSubURL is non-empty.

Using release/v1.21, several commits after the 1.21.10 release, on a server recently upgraded from 1.20.

Steps to reproduce:

1. Visit https://mydomain.com/sub_path/user/login (where ROOT_URL is configured to https://mydomain.com/sub_path/)
2. Click Remember This Device
3. Login
4. In the browser's dev tools, alter the Path of the gitea cookie from /sub_path to /sub_path/
5. Attempt to logout
6. You will now be redirected back to the home page

The logout only clears cookies in the /sub_path, not /sub_path/. Due to PR #29599, the login page now sees the gitea cookie that can't be deleted, auto logs in, and then redirects back to the home page.

Existing code already tries to delete the cookie at /sub_path. https://github.com/go-gitea/gitea/pull/24107/files#diff-7c540b84d46e33f1e7b33c7a4cc4daed15b765c11da81070d2313b42251aa48eR48-R53. But it doesn't delete cookies at /sub_path/. #29552 changed the default value of the path, but it didn't update code that clears it.

This is problematic because the longer path is more specific as far as the browser is concerned, and the browser prefers the old, outdated cookie with the trailing slash over newly set cookies. A similar problem may occur when no path is set on the cookie since browsers use the current page's path to determine the path of the cookie. The new, correct cookie path at the root should be /, but cookies without a path set may override it.

The workaround was to clear browser cookies, which is not desirable.

Solution

This PR changes it so that whenever a cookie is written, we also clear legacy cookies that could override the cookie currently being written. In this way, cookies are lazily upgraded. In the interim, legacy cookies are still sent from the browser to the server and used. This is fine.

Cookies are written in modules/web/middleware/cookie.go, but also deep inside the chi dependency. Rather than modifying the latter, we clear legacy cookies whenever regenerating a session. This is required to handle the case of an expired session that would otherwise cause a redirect loop.

Open to suggestions on a better approach.

[jtran]

I made a mistake. I will recreate the PR or re-open once fixes have been made.

[jtran]

TBH I am not sure whether my question about cookie path "" vs "/" is right, whether they are the same in browsers ....

If it is unclear/risky, maybe we should skip the "" vs "/" case .... just like your previous approach.

They're not the same. When the Go code sees a path of "", it doesn't set a path on the cookie. The default path when a path is not set depends on the URI of the page when it's set. I don't think we want cookies to be set for various paths depending on the page that was accessed. Therefore, I'm pretty sure that the latest approach of clearing out the cookie with path "" in favor of "/" is correct. Preferring "/" is much simpler to reason about. There will only be one at the root, not potentially many overriding each other depending on the current URI of the page.

That said, I have to figure out the failing tests. So we'll see where that leads me.

[jtran]

Reverting the change to delete cookies with no path fixed the integration test failures. So maybe we don't want that change. I'm a little unclear about the reasoning behind this.

I think it only matters when AppSubURL is empty, and we never observed a problem with on servers where it's empty. So I think this is fine.