Seafile redirects to an insecure connection when no URL path is provided

[multiwebinc]

When trying to go to the domain with a secure connection it redirects to an insecure connection as long as no path is provided and the user is not logged in. For example:

$ curl -Ik https://seafile
HTTP/1.1 302 FOUND
Date: Tue, 02 Feb 2016 22:49:03 GMT
Server: gunicorn/0.16.1
Transfer-Encoding: chunked
Vary: Accept-Language,Cookie
Content-Type: text/html; charset=utf-8
Location: http://seafile/accounts/login?next=/
Content-Language: en

However, if I provide a path it does not redirect:

$ curl -Ik https://seafile/accounts/login/?next=/
HTTP/1.1 200 OK
Date: Tue, 02 Feb 2016 22:53:25 GMT
Server: gunicorn/0.16.1
Transfer-Encoding: chunked
Content-Language: en
Expires: Tue, 02 Feb 2016 22:53:25 GMT
Vary: Cookie,Accept-Language
Last-Modified: Tue, 02 Feb 2016 22:53:25 GMT
Cache-Control: max-age=0
Content-Type: text/html; charset=utf-8

$ curl -Ik https://seafile/accounts/login/
HTTP/1.1 200 OK
Date: Tue, 02 Feb 2016 22:51:42 GMT
Server: gunicorn/0.16.1
Transfer-Encoding: chunked
Content-Language: en
Expires: Tue, 02 Feb 2016 22:51:42 GMT
Vary: Cookie,Accept-Language
Last-Modified: Tue, 02 Feb 2016 22:51:42 GMT
Cache-Control: max-age=0
Content-Type: text/html; charset=utf-8

If the user is logged in, going to https://seafile will work correctly.

Here is my Apache config:

<IfModule mod_ssl.c>
        <VirtualHost *:443>
                ServerAdmin webmaster@localhost
                ServerName seafile

                ProxyPass /seafhttp http://127.0.0.1:8082
                ProxyPassReverse /seafhttp http://127.0.0.1:8082
                RewriteRule ^/seafhttp - [QSA,L]

                ProxyPass / http://localhost:8000/
                ProxyPassReverse / http://localhost:8000/
                ProxyPreserveHost On

                Alias /media  /opt/seafile/seafile-server-latest/seahub/media

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on

                SSLCertificateFile /etc/letsencrypt/live/mysite.com/fullchain.pem
                SSLCertificateChainFile /etc/letsencrypt/live/mysite.com/chain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/mysite.com/privkey.pem

        </VirtualHost>
</IfModule>

An ugly hack is to redirect in Apache/Nginx to the https version, but that is not a viable solution since I believe a malicious user could still sniff the session cookie from the insecure request. Not to mention it is more inefficient since an extra request to the server must be made.

[lins05]

You need to set SERVICE_URL to https://seafile.example.com in confs/ccnet.conf when you configuring https.

http://manual.seafile.com/deploy/https_with_nginx.html

[multiwebinc]

@lins05 That didn't work. I also have it set in the settings in the web admin.

To get around this I am using Apache to forward all http connections to https, however simply trying to go to the seafile main page results in 5 separate requests to the server. Yuck!

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName seafile

        # Forward all requests to https
        RewriteEngine On
        RewriteCond %{HTTPS} !=on
        # For letsencrypt (which requires insecure connections)
        RewriteCond %{REQUEST_URI} !^/.well-known/?(.*)
        RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

        DocumentRoot /home/mike/www

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

$ curl -IkL https://seafile
HTTP/1.1 302 FOUND
Date: Mon, 08 Feb 2016 22:56:48 GMT
Server: gunicorn/0.16.1
Transfer-Encoding: chunked
Vary: Accept-Language,Cookie
Content-Type: text/html; charset=utf-8
Location: http://seafile/accounts/login?next=/
Content-Language: en

HTTP/1.1 302 Found
Date: Mon, 08 Feb 2016 22:56:48 GMT
Server: Apache/2.4.7 (Ubuntu)
Location: https://seafile/accounts/login?next=/
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 301 MOVED PERMANENTLY
Date: Mon, 08 Feb 2016 22:56:49 GMT
Server: gunicorn/0.16.1
Transfer-Encoding: chunked
Vary: Accept-Language,Cookie
Content-Type: text/html; charset=utf-8
Location: http://seafile/accounts/login/?next=/
Content-Language: en

HTTP/1.1 302 Found
Date: Mon, 08 Feb 2016 22:56:49 GMT
Server: Apache/2.4.7 (Ubuntu)
Location: https://seafile/accounts/login/?next=/
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 200 OK
Date: Mon, 08 Feb 2016 22:56:49 GMT
Server: gunicorn/0.16.1
Transfer-Encoding: chunked
Content-Language: en
Expires: Mon, 08 Feb 2016 22:56:49 GMT
Vary: Cookie,Accept-Language
Last-Modified: Mon, 08 Feb 2016 22:56:49 GMT
Cache-Control: max-age=0
Content-Type: text/html; charset=utf-8
Set-Cookie: csrftoken=...; expires=Mon, 06-Feb-2017 22:56:49 GMT; Max-Age=31449600; Path=/
Set-Cookie: sessionid=...; expires=Tue, 09-Feb-2016 22:56:49 GMT; httponly; Max-Age=86400; Path=/

[shoeper]

Seafile does not redirect to http here and it does not on seacloud.cc.

[multiwebinc]

@shoeper Well something is redirecting with my install. Any idea what it could be?

[shoeper]

Have you restartet your server after adjusting the SERVICE_URL? It could also be due to proxy usage (just an idea - maybe Django detects what protocol it was accessed by and redirects using that one).

[multiwebinc]

@shoeper Yes, I restarted the server. I'm not really sure what you mean about the proxy usage. If you want me to paste any other config files let me know. However I just checked the link that @lins05 pasted above and the nginx version of the docs does have a section in the configuration file that redirects http to https, so maybe that's there for this reason. Of course, that's just speculation.

[shoeper]

the nginx version of the docs does have a section in the configuration file that redirects http to https

then curl -IkL would have shown it - wouldn't it?

[multiwebinc]

@shoeper That's true. If you have any other ideas what's causing this let me know.

[shoeper]

Since this doesn't seem to be a bug of Seafile itself I close this ticket.

[harikattar]

Actually I'm getting the exact same thing here. nginx is forwarding https://domain/ to seahub via fastcgi on 127.0.0.1:8000, and that server is sending a redirect to http://domain/.

Edit: Nginx was missing fastcgi_param HTTPS on; fastcgi_param HTTP_SCHEME https;

PEBKAC I guess. I'll leave this here because this issue comes up on a search for "seafile redirects to insecure" and it didn't have a solution, and now it does.