gitea: Potential problem with session

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

Description

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

Screenshot from 2021-04-20 10-51-28

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?

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 39 (39 by maintainers)

Most upvoted comments

Hi!

As I wrote above you’d need to add some additional config to your app.ini to add a trace logger to modules/auth/sso.

Change your app.ini log sections to

[log]
MODE                = console, file, tracesso
LEVEL               = info
ROOT_PATH           = /storage/runtime/logs
ENABLE_ACCESS_LOG   = true

[log.file]
LEVEL               = info
FILE_NAME           = /storage/runtime/logs/activity.log

[log.tracesso]
LEVEL=trace
EXPRESSION=modules/auth/sso
MODE=file
FILE_NAME           = /storage/runtime/logs/tracesso.log

It looks like your ACCESS_LOG_TEMPLATE is just the default so you don’t need to set that.


What version exactly did you upgrade to? These log lines:

2021/05/12 14:48:31 ...c/net/http/server.go:3139:logf() [I] http: superfluous response.WriteHeader call from code.gitea.io/gitea/modules/context.(*Response).WriteHeader (response.go:67)

Shouldn’t be present in main - so I’m confused as to how you’re getting them.

#15803 is the trace logging PR

#15304 & #15303 won’t necessarily help this. I still need to pop up the logging PR and will refer to this issue once it’s up.

#15303 would rule out Basic Authentication as the cause for weird shifts so is not completely useless.