Potential problem with session

[ndaidong]

• Gitea version (or commit ref): 1.14.0
• Git version: 2.29.2
• Operating system: Debian 10.9

This gist shows detail how we setup our gitea server:

https://gist.github.com/ndaidong/2fad09f49db27d115f6d47eba7e91cb8

• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
• Log gist:

• Activity log
• Access log

Description

We've setup gitea for our company. After migrating from Bitbucket, here is what we have now:

There is often about 40 users online at any time.
Everything work well, thank you so much for your effort to build a great platform as Gitea.

However, sometimes we found that the session suddenly closes and we have to login again. It occurs with admin accounts and normal users too.

Could you give us any idea, or conjecture about this odd phenomenon?

[techknowlogick]

Just a quick note about your config, you have fully copied the app.example.ini which is for documentation purposes and not meant to be copied in full (you'll note: https://gist.github.com/ndaidong/802c8157df3771ce097a42c3c9a01b70#file-app-ini-L441 log.x doesn't actually do anything), and so you should only set settings you are confident of and leave default settings up to Gitea.

[ndaidong]

@techknowlogick yes I just modify what I need and understand. Do you mean I should remove the default parts from that .ini?

[lunny]

Is this folder exist with correct file permission? /storage/runtime/sessions

[ndaidong]

@lunny yes, the whole /storage directory is owned by git:git.

For more info, I separate into several parts, in which:

• /storage/gitea: persistent data to backup
• /storage/runtime: data generated in runtime, not saving to NAS

sysad@gitserver /storage $ tree -L 2
.
├── gitea
│   ├── repositories
│   ├── ssh
│   └── uploads
├── lfs
├── lost+found [error opening dir]
├── runtime
│   ├── indexers
│   ├── logs
│   └── sessions
└── tmp
    └── local-repo

[lunny]

default sessions is stored into files which should be persistent. Once the files deleted, the session will be invalid and users will be prompted to login.

Also default indexers will use bleve which will store as files. Once the files deleted, and Gitea will regenerated them when restart.

[ndaidong]

@lunny certainly, these files are persistent. And I can ensure that nothing affect to them while the system is working. Any suggestion to check?

[lunny]

Have you tried to upgrade to v1.14.1?

[ndaidong]

@lunny not yet. But I have plan to try. Because at least it resolves the issue superfluous response.WriteHeader .

[techknowlogick]

@techknowlogick yes I just modify what I need and understand. Do you mean I should remove the default parts from that .ini?

the file you are basing your current app.ini on is documentation and provides examples, but should NOT be use as a base with just a few things updated. You should start with an empty app.ini and only add the things you need to it.

[ndaidong]

@techknowlogick I'm upgrading to v1.14.1 and refactoring the app.ini file. Hopefully that it becomes more stable. I will update the situation after few hours of monitoring.

[ndaidong]

@lunny @techknowlogick hello, I've upgraded successfully to v1.14.1 and refactored app.ini file. Now the config file is only 4.5 kb.
It seems the session is more stable than earlier but the error "superfluous response.WriteHeader call" is still happening, and there is another issue.

[ndaidong]

@lunny Please look into this issue carefully. I believe that we are facing a serious problem here.

Some people in my company and I found that sometimes we get into other session. Let's says a user A login Gitea last night, and today morning, when A comes back, he found that the account he is using is B. In almost cases, he is being redirected to login page, but in the worst cases, he can even use B's account to navigate around and change personal settings.

The sessions have been stored into hard drive, as below:

[session]
PROVIDER          = file
PROVIDER_CONFIG   = /storage/runtime/sessions
COOKIE_NAME       = i_dont_like_cookie
COOKIE_SECURE     = true
SAME_SITE         = lax

Now we've changed to redis:

[session]
PROVIDER          = redis
PROVIDER_CONFIG   = network=tcp,addr=127.0.0.1:6379,db=0,pool_size=100,idle_timeout=180
COOKIE_NAME       = i_dont_like_cookie
COOKIE_SECURE     = true
SAME_SITE         = lax

[lunny]

Have you use a reverse proxy for your Gitea instance?

[ndaidong]

@lunny yes, we use nginx. And let's encrypt for SSL certificate.

[ndaidong]

@lunny @techknowlogick hello, this problem is still happening with us. Today at least 2 users reported: they have seen that they have been using the account of another user (same account, let's say X).

• case 1: after weekend, A opens the homepage and clicks on the signin buton --> redirect to X's dashboard without login
• case 2: B clicks on a link to an issue shared by C via Skype --> open that page under X account

IMO, the cause may not relate to the session, but SSO mechanism. I'm investigating the modules at /auth/sso, please share to me the diagrams here if any.