The VM with standard Discourse does not display such warning.
I compare the 2 configurations and found that nethserver-discourse is missing 2 folders:
For a test, I wanted to try to copy the missing folders from the standard Discourse to the nethserver-discourse.
In nethserver-discourse, I just created a folder letsencrypt and went into it.
To my surprise, even if I didn’t copy nothing yet, the folder was filled up with the same sub-folders as the standard Discourse.
In nethserver-discourse, I created a folder ssl and went into it.
Same thing, it filled up by itself.
I rebooted the nethserve-discourse and no more warning, all is OK.
Hi all and especially @stephdl on holiday in the canyon,
After 3 weeks of struggle: installation, reinstallation, standard Discourse, nethserver-discourse, Apache disable / Nginx, Nginx only, HAProxxy, Apache only, I finally found the cause of the warning in the URL bar and the unable to reconnect after “force https”.
With standard Discourse:
The warning in the URL bar is due to the installation of the Logo
It is absolutely necessary not to install the logo when connecting to Discourse for the first time.
You must install the logo only after the configuration is complete with Settings → Branding.
To correct the situation:
Remove logo in Settings → Branding.
Reinstall the logo in Settings → Branding.
Not able to login is due to Apache
In the file: /etc/httpd/conf.d/zzz_discourse.conf, just before the line ProxyPass, add this line:
RequestHeader set X-Forwarded-Proto "https"
Restart Apache
# systemctl restart httpd
‡ It should be the same with nethserver-discourse and NGINX /etc/nginx/conf.d/zzz_discourse.conf
Hi all and especially @stephdl on holiday, if he is out of the canyon,
For Nethserver-Discourse
After a backup snapshot, restart the VM
Wait at least 2-3 minutes to let time for clamd to finish.
Wait at least another 2-3 minutes to let ruby start Discourse (there are 4rubyrunning for discourse).
FILE: /etc/httpd/conf.d/zzz_discourse.conf
...
ProxyPreserveHost On
ProxyRequests Off
# Add those 2 lines to be always able to login
RequestHeader set X-Forwarded-Proto "https"
AllowEncodedSlashes NoDecode
ProxyPass / unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:/var/discourse/shared/standalone/nginx.http.sock|http://localhost/
...
Restart Apache:
# systemctl restart httpd
# systemctl status httpd | grep Active
Configuration → Parameters → Security → Activate “force https”
Refresh page - warning is still there => normal because of the “Branding icons”.
Configuration → Parameters → Branding Delete “logo” -> click the green check mark to activate the suppression Delete “small logo” -> click the green check mark to activate the suppression
Repeat if more logos.
Make sure there are no more logos.
…
Download a new “logo” -> click the green check mark to activate the new logo
Download a new “small logo” -> click the green check mark to activate the new “small logo”
Repeat if more logos.
Logout
The page refreshes to display the home page, there is no more warning in the URL bar.
Reboot, clear caches, and login to be absolutely sure that all is running perfectly.
P.S.
Use 2 different browsers to login; if you have problems after activating “force https”, you can use the other browser still logged in to deactivate it.
About X-Forwarded-Proto, We could release a prop that enables the additional headers. The prop can be enabled by default starting from 7.10. I’d avoid a new UI checkbox because the new default behavior shouldn’t harm in 98% of cases
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
RequestHeader set "X-Forwarded-SSL" expr=%{HTTPS}
Thank you for this improvement, it is appreciated.
Correct me if I’m wrong:
X-Forwarded-Proto => to pass the protocol i.e. https originated from SOURCE (client) to DESTINATION (LOCAL host)
X-Forwarded-For => to pass the IP address of the SOURCE to DESTINATION
X-Forwarded-Host => to pass the hotname of the SOURCE to DESTINATION
So those directives take care of the “Header” of the packet.
I think I have the same kind of problem - packet received by the Proxy is different from the packet received by DESTINATION. The Proxy “plays” with the packet before relaying it.
In my problem with Matrix-Synapse packet received, the packet is “canonized” before being relayed, meaning that any character %40 is replaced with @ and %3A with :
EDIT: If this packet contains a URL, itself containing the above characters, when it is received by DESTINATION it isn’t what is expected. REF:https://github.com/matrix-org/synapse/issues/10749, especially the post of richvdh.
To resolve this new problem, you have to give the option nocanon.
Normally, mod_proxy will canonicalise ProxyPassed URLs. But this may be incompatible with some backends, particularly those that make use of PATH_INFO. The optional nocanon keyword suppresses this and passes the URL path "raw" to the backend. Note that this keyword may affect the security of your backend, as it removes the normal limited protection against URL-based attacks provided by the proxy.
Martin gave me full acces to his Chat installation and I compared all the configurations with mine.
All are the same except he is running it hosted at some place meaning that it is directly connected to the Internet with nothing in front of his Chat server.
My installation is running on a LOCAL VM and my main NS server redirects all related URL/PORT to the LOCAL server.
As answered on a forum where I asked for any suggestions to resolve the problem:
… your logs showed that something upstream of your server (Apache, presumably, or possibly Cloudflare) was replacing %40 with @ in the request URI of incoming requests (and %3A with : ), hence invalidating the signature made by the sending server.
I suspect that it is my main NS server redirections that are replacing the %40, the %3A, etc… characters but I don’t know if it is the URL or the Port redirections doing it.
I checked /etc/httpd/conf.d/virtualhosts.conf and nowhere there is a nocanon directive parameter.
Since my main server is quite full of all kind of modules/applications which are all working correctly, I don’t want to do a mistake by changing an unappropriate parameter.
Usually, nocanon goes after the retry=30 as in the line below.
Where do you think I should insert the nocanon for the corresponding lines?
Should I modify with a custom template and which ones ?
Will it affect all other vhosts I have, like mediawiki, etc ?