Wrong Redirect after Login

I’m trying to seafile behind an Apache proxy under a subpath of the Apache sever (i.e. > https://server.tld/seafile). After login the browser gets redirected to > https://server.tldseafile (note missing ‘/’ between hostname and subpath).
Once I manually correct the URL in the browser’s URL bar everything works fine, so it seem as if only the initial redirect after login isn’t working. What am I doing wrong?

Check admin panel and SITE_ROOT what is setup
Check seahub_settings.py for SITE_ROOT
Check ccnet.conf for SERVICE_URL

I’m sure that’s in seafile configuration.

There is no SITE_ROOT in the admin panel - only SERVICE_URL which is set to https://server.tld/seafile
(the same as in ccnet.conf). The SITE_ROOT is configured in seahub_settings.py to ‘/seafile/’.

@daniel.pan I see that after login seafile remove ending slash from url https://seafile.tld instead of htttp://seafile.tld/

Bingo - I found the bug. Not where I expected it! After login the server sends a 302 response with a ‘location’ header set to ‘http://server.tld/seafile/’ - note the chaged protocol (from https -> http). That triggered a rewrite rule on my Apache server to redirect to the https version. Why does seafile redirect to http? This seems like a dangerous (security relevant) bug to me. After all that results in the login credentials (cookie) being sent over an unencrypted connection.

No, you have some mistake in configuration, all my seafile instance redirecting direct to HTTPS there’s no unencrupted connection. But if is your login form under HTTPS then you don’t have to be scared about credentials cause sign in form sending form to same page and after that is redirect(if credetials are right) to seafile page(your HTTP request).

Sorry, but I just checked the TCP traffic between seafile and the Apache proxy - upon successful login seafile sends an response (over the encrypted connection) with status code ‘302 FOUND’ and a ‘Location’ header with the http (!sic) protocol. This triggers the browser to request that http resource (read: over an unencrypted connection). I’m not scared about my login credentials, I’m scared about the CSRF token leaking out through the insecure http connection and I’m feeling uneasy about the session cookie leaking out as well (which, IMHU, would allow a man-in-the-middle session take-over).

That’s true but it’s not checking anything on that you have something bad in configuration. As I said, I have no HTTP connection in seafile.

And you are relly running seafile behind a proxy?

Yes, both but not in subfolder only on subdomain.

Hmm - after looking at the source code that is hard to belive. This seems to be a well-known django problem and the fix for this seems to be to have the proxy server send a X-Forwaded-Proto header to the seafile server. That does fix my problem, no more http-redirects.
So this is a (rather dangerous) bug in the official documentation.

Maybe you can contribute to https://github.com/haiwen/seafile-docs