Closed saegl5 closed 1 year ago
I have frequently encountered an issue with images: They stop loading, and then users are immediately logged/"kicked" out.
I haven't fully understand your problem.
Do you mean that: if a user visits an image URL, then the user gets signed-out?
Clearing web browser history temporarily fixes the issue, for perhaps one minute.
I do not think it is related.
app.ini
, especially COOKIE
related settings?I tried to reproduce the bug on the Gitea demo site, but the site won't allow me to even log in. Error code 500.
Which page? I just tried, I can login try.gitea.io.
I can visit it with no problem. macOS both firefox and safari.
@wxiaoguang
LOGIN_REMEMBER_DAYS = 7
and still encountered my issue)@wxiaoguang and @lunny
try.gitea.io works for me now, thanks \
I don't encounter the issue in it CORRECTION: I do encounter the issue
- session storage: Web Inspector > Storage I see unexpired cookies and Dark Reader
What's the session related config in your app.ini
?
Since you can't reproduce the problem on try.gitea.io, I suspect that this problem is related to your server-side session storage.
If you have no idea about how to continue debugging, a clear & minimal reproducible sample should help, eg: you could try to setup a small and clear instance, to try whether it has the same problem. If yes, report the details here then maintainers could help to reproduce and debug. If the new instance doesn't have the problem, then try to find what's the difference between it and your production instance, by fine-tuning the config options step by step.
@wxiaoguang
app.ini:
APP_NAME = VCS Portal
RUN_USER = gitea
RUN_MODE = prod
[database]
DB_TYPE = sqlite3
HOST = 127.0.0.1:3306
NAME = gitea
USER = gitea
PASSWD =
SCHEMA =
SSL_MODE = disable
CHARSET = utf8
PATH = /var/lib/gitea/data/gitea.db
LOG_SQL = false
[repository]
ROOT = /var/lib/gitea/data/gitea-repositories
ENABLE_PUSH_CREATE_USER = true
DISABLE_STARS = true
[server]
SSH_DOMAIN = questabox-vcs.dev
DOMAIN = questabox-vcs.dev
HTTP_PORT = 3000
ROOT_URL = https://questabox-vcs.dev/
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true
LFS_JWT_SECRET = [redacted]
OFFLINE_MODE = false
[lfs]
PATH = /var/lib/gitea/data/lfs
[mailer]
ENABLED = true
SMTP_ADDR = smtp.gmail.com
SMTP_PORT = 465
FROM = [redacted email address]
USER = [redacted email address]
PASSWD = [redacted]
[service]
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL = true
DISABLE_REGISTRATION = true
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
ENABLE_CAPTCHA = false
REQUIRE_SIGNIN_VIEW = false
DEFAULT_KEEP_EMAIL_PRIVATE = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING = true
NO_REPLY_ADDRESS = noreply.localhost
[picture]
DISABLE_GRAVATAR = false
ENABLE_FEDERATED_AVATAR = true
[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false
[session]
PROVIDER = file
[log]
MODE = file
LEVEL = info
ROOT_PATH = /var/lib/gitea/log
ROUTER = console
[repository.pull-request]
DEFAULT_MERGE_STYLE = merge
[repository.signing]
DEFAULT_TRUST_MODEL = committer
[security]
INSTALL_LOCK = true
INTERNAL_TOKEN = [redacted]
SECRET_KEY = [redacted]
PASSWORD_HASH_ALGO = pbkdf2
[ui]
THEMES = auto,gitea,arc-green,auto-red,red,arc-red
DEFAULT_THEME = auto-red
THEME_COLOR_META_TAG = none
No idea from my side (it doesn't look like a Gitea's problem at the moment)
Could you try to setup a clear & minimal instance to see whether the problem would occur?
@wxiaoguang thank you for your input and for following up
I feel odd—a bit embarrassed too—to find that the issue went way after checking "Remember This Device" before logging in
although checking that option seems logical to work, since I never had to check that option until recently, then checking that options seems to be a sort of workaround
tonight, I'll try to setup a small and clear instance, as you suggested it could be a server-side issue, yeah
@wxiaoguang okay, small and clear instance:
http://34.82.68.62:3000 \
username: admin-testing \
password: 123456 \
(my only change was to make user visibility private)
closed this instance, used try.gitea.io instance (see below)
> There is nothing private or confidential in this instance...
Issue occurs here too. \ Just give it time; open other tabs; click around Gitea (dashboard, dashboard repository links, open dashboard in new tab, etc.) \ Eventually, I start to frequently see my issue. \ Come to think, if I keep user visibility public, then the images might still show but I may still be logged out. I want user visibility to be private, though.
Again, yes, it could be server-side. I now see have seen the issue in try.gitea.io \
https://try.gitea.io/saegl5/myprojects-testing \
username: saegl5 \
password: 123456
(user visibility private)
closed this instance, too
anyways, for now I am reminding myself to check "Remember This Device" before logging in I would assume that, even with the box unchecked, that users would stay authenticated for 7 days (well, at least longer than what I am getting)
OK, I know the problem now. It's related to Safari & Gitea's session management.
The key point is that "two tabs", then the previous tab's cookie session changed: need more clues
OK, I 99% understand the problem now. It's highly likely a Safari bug.
At the beginning, Safari sends Cookie with Avatar requests.
But after a few minutes, Safari only sends Cookie with page request, but doesn't send Cookies with Avatar request.
Then , the avatar request can't see a session cookie, then the handler (middleware) allocates a new session ID, then this cookie is applied to the whole site, then you are in a non-signed-in session.
According to my test, disabling this option could fix Safari's buggy behavior (actually, Google result shows that a lot of users are affected by similar buggy behavior)
Screenshot:
@wxiaoguang wow! great work!
kindly note, however, that—as also noted above—disabling preventing cross-site tracking didn't work for me \
however, I'll retry... yeah, no difference
glancing at commit 808acb51c69e3decf2cff429060db04f519f9c7d > routers/web/web.go diff... \
okay, yeah, #24330 could work: looks like the handler won't be used, meaning no new cookie if the avatar request can't see one never mind, I see what you did in the linked diff above
this all seems to be making sense to me now thank you, again
Description
Ever since Gitea Version 1.19.0, I have frequently encountered an issue with images: They stop loading, and then users are immediately logged/"kicked" out. Error code 404: "The page you are trying to reach either does not exist or you are not authorized to view it."
Clearing web browser history temporarily fixes the issue, for perhaps one minute. This issue only occurs in Safari (desktop and mobile), neither Chrome, nor Firefox, nor DuckDuckGo.
Also, this issue only occurs in my Gitea instance, no other websites.Other observations: The file type doesn't matter (e.g., JPEG and GIF). I also attempted disabling the development menu, using a different MacBook, using safe mode, emptying Safari's caches, using the private window, using a different account (e.g., admin and dummy user), disabling Private Relay, disabling plug-ins, disabling privacy features (e.g., preventing cross-site tracking), changing the DNS to CloudFlare's, restarting my internet router, trying Safari Technology Preview, removing content blockers, and disabling iCloud's Safari sync.
I tried to reproduce the bug on the Gitea demo site, but the site won't allow me to even log in. Error code 500.(Can log in, now.)Might the way in which Gitea interacts with Safari, in regards to cookie behavior, have changed? Perhaps?
Debug log:
Gitea Version
1.19.1
Can you reproduce the bug on the Gitea demo site?
No
Screenshots
Example of image not loading: \
Git Version
2.40.0
Operating System
Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-1031-gcp x86_64)
How are you running Gitea?
I run Gitea in a Google Cloud instance, and the Gitea package is installed using instructions from https://gitlab.com/packaging/gitea/
Database
SQLite