github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-09 04:25:18 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Memory session provider does not return private repositories in dashboard search #8276

New Issue
Closed
opened 2025-11-02 08:00:36 -06:00 by GiteaMirror · 13 comments
GiteaMirror commented 2025-11-02 08:00:36 -06:00
Owner
Copy Link

Originally created by @jprjr on GitHub (Dec 22, 2021).

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":

image

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

image

Originally created by @jprjr on GitHub (Dec 22, 2021). ### 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": ![image](https://user-images.githubusercontent.com/4265148/147105929-2db05446-7773-4a52-9e48-5f53c8ed0940.png) And here is a screenshot with the session provider changed to "memory" - notice the private repo is not listed. ![image](https://user-images.githubusercontent.com/4265148/147105897-dd7f6fa1-02ab-4d6a-86ee-36fa3fb4aa73.png)
GiteaMirror added the issue/needs-feedbacktype/bug labels 2025-11-02 08:00:36 -06:00
GiteaMirror commented 2025-11-02 08:00:37 -06:00
Author
Owner
Copy Link

@Ma27 commented on GitHub (Dec 23, 2021):

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

@Ma27 commented on GitHub (Dec 23, 2021): I can confirm that this is an issue and I only observed it since 1.15.8.
GiteaMirror commented 2025-11-02 08:00:37 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Dec 24, 2021):

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.

@techknowlogick commented on GitHub (Dec 24, 2021): 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.
GiteaMirror commented 2025-11-02 08:00:37 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 24, 2021):

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 commented on GitHub (Dec 24, 2021): This is weird. The only thing it could possibly relate to is the regenerate session id stuff but I don't completely understand how.
GiteaMirror commented 2025-11-02 08:00:38 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 24, 2021):

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?

@zeripath commented on GitHub (Dec 24, 2021): 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?
GiteaMirror commented 2025-11-02 08:00:38 -06:00
Author
Owner
Copy Link

@rampd2 commented on GitHub (Dec 24, 2021):

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). :/

@rampd2 commented on GitHub (Dec 24, 2021): 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). :/_
GiteaMirror commented 2025-11-02 08:00:38 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 25, 2021):

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?

@zeripath commented on GitHub (Dec 25, 2021): 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?
GiteaMirror commented 2025-11-02 08:00:39 -06:00
Author
Owner
Copy Link

@deanpcmad commented on GitHub (Dec 27, 2021):

Also having the same issue. Version 1.15.7 works fine.

@deanpcmad commented on GitHub (Dec 27, 2021): Also having the same issue. Version 1.15.7 works fine.
GiteaMirror commented 2025-11-02 08:00:39 -06:00
Author
Owner
Copy Link

@jprjr commented on GitHub (Dec 27, 2021):

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 353d88a42e): only the public repository is listed.
  • main branch (commit d2fac636d1): both repositories listed.
@jprjr commented on GitHub (Dec 27, 2021): 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 353d88a42e2bfce9ba8923ad2ef3f2601ab65286): only the public repository is listed. * main branch (commit d2fac636d16a596a36a3088ff05ffe812ba6eff2): both repositories listed.
GiteaMirror commented 2025-11-02 08:00:39 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 28, 2021):

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.

@zeripath commented on GitHub (Dec 28, 2021): 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.
GiteaMirror commented 2025-11-02 08:00:40 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Dec 30, 2021):

@deanpcmad @jprjr can you please confirm the pull fixed it or if it still exist

@6543 commented on GitHub (Dec 30, 2021): @deanpcmad @jprjr can you please confirm the pull fixed it or if it still exist
GiteaMirror commented 2025-11-02 08:00:40 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 31, 2021):

@6543 They have confirmed in the PR https://github.com/go-gitea/gitea/pull/18114#issuecomment-1002235695 . So let's close this one.

@lunny commented on GitHub (Dec 31, 2021): @6543 They have confirmed in the PR https://github.com/go-gitea/gitea/pull/18114#issuecomment-1002235695 . So let's close this one.
GiteaMirror commented 2025-11-02 08:00:40 -06:00
Author
Owner
Copy Link

@Ma27 commented on GitHub (Jan 2, 2022):

I can also confirm that this issue is now resolved with 1.15.9, thanks!

@Ma27 commented on GitHub (Jan 2, 2022): I can also confirm that this issue is now resolved with 1.15.9, thanks!
GiteaMirror commented 2025-11-02 08:00:41 -06:00
Author
Owner
Copy Link

@deanpcmad commented on GitHub (Jan 2, 2022):

Can confirm it's fixed. Thanks :)

@deanpcmad commented on GitHub (Jan 2, 2022): Can confirm it's fixed. Thanks :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/needs-feedback type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#8276
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?