search

RocketChat / Rocket.Chat

The communications platform that puts data protection first.
https://rocket.chat/
Other
40.8k stars 10.72k forks source link

SVG icons in sidebar/toolbar don't render on current desktop Firefox for Linux, ?https issue? #10664

Open PhilGPk opened 6 years ago

PhilGPk commented 6 years ago

Description:

When logged in to Rocket.Chat hosted via Apache reverse-proxy over https, the six icons in the toolbar (for search, directory, etc.) don't appear. Client browser is Firefox 52.7.3 ESR 64 bit on Linux.

It does work on Firefox 59.0.2 on Android and Chromium on the same Linux machine as before. So "further debugging" below. It appears to be an interaction of the ESR version of Firefox with the https proxy.

Server Setup Information:

Rocket.chat's being served via an Apache reverse-proxy setup on a HTTPS server.

RewriteEngine On RewriteCond %{REQUEST_URI} ^/rocketchat$ RewriteRule /rocketchat https://the.host.name/rocketchat/ [R,L] RewriteCond %{REQUEST_URI} ^/rocketchat/(.) RewriteCond %{HTTP:Upgrade} =websocket [NC] RewriteRule /(.) ws://localhost:3000/$1 [P,L] RewriteCond %{REQUEST_URI} ^/rocketchat/(.) RewriteCond %{HTTP:Upgrade} !=websocket [NC] RewriteRule /(.) http://localhost:3000/$1 [P,L] ProxyRequests Off ProxyPassReverse /rocketchat/ "http://localhost:3000/"

Steps to Reproduce:

  1. Set up the server (as above, tarball, Apache reverse-proxy, rewrite rules).
  2. Login.

Expected behavior:

See the various icons in the toolbar, e.g., search, directory, ...

Actual behavior:

Not seen.

Further debugging:

This looks very similar to issue 7980. The problematic browser works fine if connecting via http (not https) directly to port 3000. So I suspected something weird around those differences. Experimentation by using Firefox's debugger to change the href links in the svg/use elements found that by having the full https://the.host.name/home#icon-whatever was the problem. Replacing this with home#icon-whatever works.

Based on kimgb's script in issue 7980, I found that this fixed it (at least, I haven't found it broken again yet): $(document).ready(function(){ $("svg > use").map(function(){ var svg_string = $(this)[0].href;

if (svg_string.baseVal.startsWith("https://the.host.name/home#")){
  svg_string.baseVal = svg_string.baseVal.replace("https://the.host.name/home#", "home#"); 
  svg_string.animVal = svg_string.animVal.replace("https://the.host.name/home#", "home#");
}

}); })

mjovanovic0 commented 6 years ago

This seems to be issue with Firefox and Content Security Policy.

Had same issue and in console there are no error but got warning: Content Security Policy: The page’s settings blocked the loading of a resource at

Quick workaround was to disable CSP by navigating to about:config and flip security.csp.enable to false.

Proper fix should be applied on server side in a way to serve SVG with proper HTTP headers as described in CSP Docs.

PhilGPk commented 6 years ago

For my setup: Checking the Firefox console: no warnings about CSP. Setting security.csp.enable to false didn't fix the issue for me, either. Also tried configuring Apache to set an "allow everything" CSP: this actually upset Firefox even more!

PhilGPk commented 6 years ago

Rocket.Chat really didn't seem to like being a redirect of this.host.name/something. Replacing the configuration with its own virtualhost where it was at the server root solved the problem I've reported in this issue, too.