Memory session provider does not return private repositories in dashboard search

[jprjr]

Gitea Version

1.15.8

Git Version

git version 2.30.1 (Apple Git-130)

Operating System

macOS 11.6

How are you running Gitea?

Running gitea with a pre-built download from the releases page (https://github.com/go-gitea/gitea/releases/tag/v1.15.8).

Running locally, ran the installer and selected a SQLite database and "local mode"

After installation, changed the session provider from "file" to "memory"

Database

SQLite

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/jprjr/36ffebe2652bfc68ac4e24c67e2841e1

Description

When using the "memory" provider, the dashboard page's repository list (and search results) does not include private repositories created by the logged-in user.

Viewing the profile page does show them, it only seems to affect the search box on the dashboard page.

Screenshots

Here is a screenshot with the session provider on the default, "file":

And here is a screenshot with the session provider changed to "memory" - notice the private repo is not listed.

[Ma27]

I can confirm that this is an issue and I only observed it since 1.15.8.

[techknowlogick]

There was a user in discord who was also able to confirm this(mcraftdan). I suspect it is likely related to the security fix that went in for session regeneration, although I'd expect it to affect all session types rather than just in memory.

[zeripath]

This is weird. The only thing it could possibly relate to is the regenerate session id stuff but I don't completely understand how.

[zeripath]

I can't reproduce this on my testing server. Have you changed cookie settings? Is your ROOT_URL correct?

If you look in your browser console and watch as you login are the cookies being set correctly?

[rampd2]

Yes, I've set GITEA__session__COOKIE_SECURE=true and GITEA__session__DOMAIN=sub.domain.tld (obviously replaced by correct subdomain, domain and top level domain). Also the GITEA__server__ROOT_URL is set to the same address just with https:// prefixed.

The last thing I can't test because I can currently only look into my configs (no server connection). :/

[zeripath]

I don't think you need to set the DOMAIN it should just get the right thing automatically.

You definitely haven't set SAME_SITE?

What browser are you using?

[deanpcmad]

Also having the same issue. Version 1.15.7 works fine.

[jprjr]

Did some testing, hopefully these steps can be used to reproduce the issue:

• checked out source, ran TAGS="bindata sqlite sqlite_unlock_notify" make build
• ran ./gitea, opened my web browser to http://localhost:3000
• on the installation screen, changed the following settings:
  • database type: SQLite 3
• clicked the install button
• registered a new account
• created two new repositories:
  • one with everything set to default
  • the other with "make private repository" checked
• view the dashboard, observe both repos are listed
• killed gitea process (ctrl+c)
• edited custom/conf/app.ini, changed the session provider from file to memory
• launch gitea again, login, check if both repositories are listed.

Here's what I observed with different versions. I checked out the code for each version to their own folder, meaning I re-ran the installer for each version. I tested these all with Firefox and Google Chrome, using my regular profile as well as private browsing / incognito. Tried with and without disabling cache, all the same. Also, using Linux in these tests.

• version 1.15.7: both repositories listed.
• version 1.15.8: only the public repository is listed.
• release/1.15 branch (commit 353d88a): only the public repository is listed.
• main branch (commit d2fac63): both repositories listed.

[zeripath]

OK I've put up a PR that I think might possibly solve the problem but I still cannot reproduce this bug. However, I am only trying on linux so it's possible that the problem is some mac issue.

The Heisenbug nature does make think that this could indeed be due to some sort of race but it may be due to difference in the way that mac handles passing cookies.

If #18114 does not solve the problem - it would be helpful to review an app.ini that reproduces the problem. If you need to censor ensure that you censor things to the same thing - e.g. DOMAIN=<censored_domain, ROOT_URL=https://<censored_domain>/<censored_suburl> and the like.