Seafile 6.2.2 CE: When I want to share a file and start searching for a user in the share dialogl, the avatar is missing. The API request returns “http://127.0.0.1:8000/media/avatars/…” as avatar_url which is not right I guess.
Avatars in general (profile, login, etc.) are working fine.
Can anybody confirm this?
Yes, I just installed 6.2.2 and am experiencing the same issue.
A solution for Apache at least: Add ProxyPreserveHost On to the Seahub section.
See https://github.com/haiwen/seafile-client/issues/965
Now I have to figure out how to change the protocol from http to https in the API request as I am strictly serving https on my server.
Using ProxyPreserveHost is causing more trouble than doing good (Cross reference: [Partially solved...] Seafile server redirects to http, despite config set to 'https://...')
I just switched back from WSGI to FastCGI config for Seahub for testing purposes and all troubles are gone, especially
So does anyone have a working vhost config for Apache and WSGI? The one provided in the manual is not working entirely.
I experienced the same issue, use https behind a proxy server, file sync is fine, avatar not showing, applet.log says
"[11/17/17 17:33:19]request failed for http://xxxxxx/media/avatars/b/4/86b7c274204e89443dac7468a6d86a/resized/80/86189b18797a325e2b905cea301c145f_d4UWY5b.png:
seems it still use http but not https
I experienced the same Issue. Not only with the avatars but with the 2F-Authentication also.
Tested with Version 6.2.5 (CE) and 6.2.9 (Pro):
Is it possible that in this relavant code snippets the server/port part of the URLS is taken from the HTTP-Request reaching 127.0.0.1:8000 and not from the config (where it should be the correct domain)?
Same problem my here with Apache+https+Pro 6.2.9. Waiting for a good solution.
Still back on FastCGI. 
After upgrading to 6.2.X, I had a very similar issue. The API returned http instead of https:, but mine was at login. I finally came up with a solution. I am on NGinx, but I would assume that Apache has a similar setting somewhere.
The fix involves changing the NGinx config file for the site. Replacing
proxy_set_header Host $host; with proxy_set_header Host $host:$server_port; did the trick.
More details on the problem can be found here.
Since upgrade, WebUI redirects with NGinx on alternate listen port [Possible Bug] [Work-Around].
This issue is affecting me as well. Would really be good to get the correct Apache2 config published.
With 6.3.0 I finally have to switch to WSGI, but I’m still struggling with a working Apache config for avatars because they are still partially delivered via http and not https.
I found workarounds for both existing problems with avatars (windows client & API call in share dialog), but they should be both https in the first place.
As a temporary solution I just rewrite the http calls to https. But with the strict browser settings I am using, the share dialog will still produce mixed content. I could solve this with changing
"avatar_url": request.build_absolute_uri(url),
to
"avatar_url": url,
in seahub\seahub\api2\endpoints\search_user.py (Line 172).
My apache config looks like this
<VirtualHost *:80>
ServerName seafile.myserver.com
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://seafile.myserver.com/$1 [R=301,L]
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName seafile.myserver.com
DocumentRoot /var/www/html
SSLEngine on
SSLCertificateFile /etc/ssl/certs/myserver.com.pem
SSLCertificateKeyFile /etc/ssl/private/myserver.com.key
##
# Seafile media
##
Alias /media /opt/seafile/seafile-server-latest/seahub/media
<Location /media>
ProxyPass !
Require all granted
</Location>
##
# Seafile fileserver
##
<IfModule mod_rewrite.c>
RewriteEngine On
ProxyPass /seafhttp http://127.0.0.1:8082
ProxyPassReverse /seafhttp http://127.0.0.1:8082
RewriteRule ^/seafhttp - [QSA,L]
</IfModule>
##
# Seahub WSGI
##
<IfModule mod_wsgi.c>
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8000/
ProxyPassReverse / http://127.0.0.1:8000/
</IfModule>
</VirtualHost>
</IfModule>I tried to find something similiar working for Apache but I was not sucessful yet.
Good hint. I did a search of the source code. It looks like there are many other places that need to modify as well, besides the one you point out.
/codebase/third_party/seafile/seafile_server/seafile-pro-server-6.2.1/seahub/seahub/api2/utils.py:
445: avatar_url = request.build_absolute_uri(d['avatar_url'])
/codebase/third_party/seafile/seafile_server/seafile-pro-server-6.2.1/seahub/seahub/api2/views.py:
3717: d['avatar_url'] = request.build_absolute_uri(url)
4115: "url": request.build_absolute_uri(url),
4128: "url": request.build_absolute_uri(url),
/codebase/third_party/seafile/seafile_server/seafile-pro-server-6.2.1/seahub/seahub/api2/endpoints/group_discussions.py:
75: "avatar_url": request.build_absolute_uri(info["avatar_url"]),
117: "avatar_url": request.build_absolute_uri(info["avatar_url"]),
/codebase/third_party/seafile/seafile_server/seafile-pro-server-6.2.1/seahub/seahub/api2/endpoints/groups.py:
62: "avatar_url": request.build_absolute_uri(avatar_url),
/codebase/third_party/seafile/seafile_server/seafile-pro-server-6.2.1/seahub/seahub/api2/endpoints/search_user.py:
172: "avatar_url": request.build_absolute_uri(url),
/codebase/third_party/seafile/seafile_server/seafile-pro-server-6.2.1/seahub/seahub/group/utils.py:
103: "avatar_url": request.build_absolute_uri(avatar_url),
/codebase/third_party/seafile/seafile_server/seafile-pro-server-6.2.1/seahub/seahub/two_factor/gateways/twilio/gateway.py:
55: uri = request.build_absolute_uri(url)
/codebase/third_party/seafile/seafile_server/seafile-pro-server-6.2.1/seahub/seahub/wopi/views.py:
165: absolute_uri = request.build_absolute_uri('/')
It looks like the function build_absolute_uri is not doing the right job. I am considering a way to replace this function.
@Martin @caniwi @wthess @sebi @lilarcor @holantomas @daniel.pan @Andrew_Powell
Issue solved, following this post https://blog.ubuntu.com/2015/08/18/django-behind-a-proxy-fixing-absolute-urls
There are two steps, without need to change any source code.
#
# seahub
#
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
RequestHeader set X-Forwarded-Proto 'https' env=HTTPS
ProxyPass / http://127.0.0.1:8000/
ProxyPassReverse / http://127.0.0.1:8000/
USE_X_FORWARDED_HOST = True
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
By the way, I would suggest to change the default values of USE_X_FORWARDED_HOST and SECURE_PROXY_SSL_HEADER in Django for the next-version of Seafile, so that the user doesn’t have to change the seahub_setting.py. The apache configuration in the document is also needed to update.
That did the trick. Thank you very much for debugging.
Yes, thanks for sharing, I notice your solution now cause didn’t got notification.
Did I got it right that seahub shares configuration directives with build-in gunicorn? Or USE_X_FORWARDED_HOST and SECURE_PROXY_SSL_HEADER are seahub only which saying how to start gunicorn?
I don’t quite get your problem. Could you elaborate more about which notification?
I think the py setting in the seahub will be loaded by gunicorn.
Just didn’t get notification, you wrote in this topic.
I have the same problem described above. I tried the solution with the change of apache/seahub settings an settings in seahub_setting.py from 1111
Unfortunately these changes do not solve the problem at my installation (Seafile 7.0.4, Apache 2.4)
You have any hints for me where i can take a look ?