Avatar in share dialog missing


#1

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?


#2

Yes, I just installed 6.2.2 and am experiencing the same issue.


#3

Same here

@daniel.pan


#4

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.


#5

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

  • avatar in share dialog missing
  • avatar in (Windows) client missing
  • client is attempting to connect to 127.0.0.1 (see Github issue)

So does anyone have a working vhost config for Apache and WSGI? The one provided in the manual is not working entirely.


#6

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


#7

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

  • Apache config according to server manual (HTTPS Reverse Proxy)
  • Avatars in Share Dialogue are tried to load from “http://127.0.0.1:8000”: Avatars are broken, HTTPS OK
  • Title for Entry in Google Authenticator is “127.0.0.1:8000”.
  • Apache config according to server manual (HTTPS Reverse Proxy) with ProxyPreserveHost ON
  • Avatars are requested from the correct domain on port 80, redirected by apache to 443 and displayed coorectly. The HTTPS Icon in the Browser changed to broken because of the redirect from port 80.
  • Title in Google Authenticator is correct domain without ports.

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)?


#8

Same problem my here with Apache+https+Pro 6.2.9. Waiting for a good solution.


#9

Still back on FastCGI. :grin:


#10

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].


#11

This issue is affecting me as well. Would really be good to get the correct Apache2 config published.


#12

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>

#13

I tried to find something similiar working for Apache but I was not sucessful yet.


#14

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.


#15

@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.

  • The apache configuration (seahub section):
    #
    # 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/
  • Add these two lines to seahub_setting.py in the conf folder
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.


#16

That did the trick. Thank you very much for debugging.


#17

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?


#18

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.


#19

Just didn’t get notification, you wrote in this topic.