Seahub stuck loading after login since upgrade to 6.3.4

seahub

#1

Hello,

I have upgraded seafile from 6.2.5 to 6.3.4 (did previous upgrades multiple times)

Everything worked well but now if I start seahub, login page shows and after filling credentials, I see endless spinner, no interface shows up.

Nothing suspicious in logs other then this in seahub.log (found out on forum it is bug of older clients)

2018-11-09 08:47:01,790 [WARNING] django.request:152 get_response Not Found: /media/assets/scripts/app/main.js
2018-11-09 08:47:07,003 [WARNING] django.request:152 get_response Not Found: /api2/events/

Can you point me a direction what to troubleshoot or how to evoke some detailed logging?

Thank you, configs follow (had to prefix links with link word)

seahub_settings.py

SECRET_KEY = “b84#z_86**ylpgfefdu_+f0f1_gxs=!&mxt61egh59sb)1scc*”

HTTP_SERVER_ROOT = ‘linkhttps://files.deymed.com’

DATABASES = {
‘default’: {
‘ENGINE’: ‘django.db.backends.mysql’,
‘NAME’: ‘seahub’,
‘USER’: ‘seafile’,
‘PASSWORD’: ‘xxx’,
‘HOST’: ‘127.0.0.1’,
‘PORT’: ‘3306’,
‘OPTIONS’: {
‘init_command’: ‘SET default_storage_engine=INNODB’,
}
}
}

EMAIL_USE_TLS = True
EMAIL_HOST = ‘my’
EMAIL_HOST_USER = ‘acaca’
EMAIL_HOST_PASSWORD = ‘xxx’
EMAIL_PORT = 5555
DEFAULT_FROM_EMAIL = ‘cloud@deymed.com’
SERVER_EMAIL = ‘cloud@deymed.com’

LOGO_PATH = ‘custom/logo_site.png’
LOGO_WIDTH = 161
LOGO_HEIGHT = 45
DEBUG = True

seafile.conf

[network]
port = 12001

[httpserver]
port = 8082

[database]
type = mysql
host = 127.0.0.1
port = 3306
user = seafile
password = xxx
db_name = seafile
connection_charset = utf8

ccnet.conf

[General]
USER_NAME = server
ID = 5bdd309159f5662f11c8d1660cf5f12223525bb3
NAME = server
SERVICE_URL = linkhttps://cloud.deymed.com

[Network]
PORT = 10001

[Client]
PORT = 13418

[Database]
ENGINE = mysql
HOST = 127.0.0.1
PORT = 3306
USER = seafile
PASSWD = xxx
DB = ccnet
CONNECTION_CHARSET = utf8

seafdav.conf

[WEBDAV]
enabled = true
port = 8080
fastcgi = false
share_name = /


#2

I just upgraded to 6.3.4 and have the same issue. I wiped my browser history without success. Any solutions?


#3

nginx or apache?


#4

I’m running apache on an Ubuntu installation.


#5

Same for me after upgrading from 6.3.2 to 6.3.4 with Ubuntu 18.04 + Apache. Cleaned browser cache & cookies, tried Firefox & Chrome… nothing’s working.
Maybe it’s time to look for a new cloud storage, this isn’t the first time that stuff like this is happening.


#6

Interesting. With Debian 9 and nginx I never had such problems. The one problem I had after upgrading to 6.3, was caused by my strict files acces rules. Many just forgot to look into their logs and start using their brain to solve it. If you don wan’t this mess you should migrate to docker.

You know this is a security issue?


#7

I rolled back to 6.3.2 and used Chrome to log in. Worked great. I logged out.
Upgraded to 6.3.4 and now I can log in with chrome. But firefox still hangs during login.
Repeated the experiment by rolling back to 6.3.2 again. Logged in with firefox and out again. Upgraded and now both firefox and Chrome are both fine.

Last thing, wiped the history and cookies on firefox. As expected he’s no longer capable of logging in to seacloud.(Its really the only place history could live!)


#8

WTF? How did this help?


#9

I assume the older version is dropping a cookie on the browser. The newer version works fine with the older cookie but fails to drop the cookie itself. So once the cookie is wiped (or a new pc tries to login) it fails.

Heck I don’t know. But that’s what I observe.

And its version 6.3.3 which was the first to fail this way. I had skipped straight from 6.3.2 to 6.3.4 but yesterday I downloaded 6.3.3 to do the testing.


#10

It was only testing instace so the secret is not valid.

After a lot of fidling with different seafile instances and stumbling across redirect loop (described in different unanswered thread) It magically started to work but it was real hastle to get it working.
I do have seafile behind two machines with apache2 reverse proxy setup because of lack of IPv4 adresses.

Docker is least favourable option for me since I have no experience with it so it would be blackbox for me to get it working and maintain it.

I am surprised that there is not functional advice yet since it affects many users.


#11

i had the same issue, and i guess i figured it out…
the problem was the Content-Security-Policy in my apache-config -> turned off=worked