Ola companeros
I am looking for someone who would like to test a trivial bug
Really thank in advance, ping me for explanations if needed
The purpose is to test that websocket path got the good input validation
So how would I go about testing this for you? Make a reverse proxy to a web socket application with a funny symbol in the url? For example have my nethserver of demo.example.com have a revers proxy to an internal web socket service with a domain pointing to http://h@ppy.example.com and see if it rejects that rule?
I need to see if you can make a custom websocket path with only A-Za-z_-/
all others must be refused
I’m still trying to learn how to follow along and install your specific changes above, once I have that I can test this for you within 30 min.
2 Likes
to test (preferably on a VM)
yum update nethserver-httpd* --enablerepo=nethserver-testing
yes so the validation works, what about if you use
/webtop-tatt_
above should work
below must be blocked
tttr’yyyt@
Pretty late to the party but I just created a reverse proxy to a dockerized instance of node-red with default websocket support activated and it works ! My last try to reverse proxy node-red using NS failed, so it’s good news !
1 Like
The whole websocketpath concept it unnessary.
The trick in my solution, to make this completely unnessary, is to dynamically detect ALL websockets protocoll change requests and proxy these dynamically. See discussion above. This parameter is unnessary and just irritates people, because they think they have to specifiy the websocket path, but can only do this, when the checkbox for dynamic detection is already activated. Webtop, Nextcloud work with the checkbox only, without specifying the websocket path.
In fact, with the current implementation there is NO situation, where this web socket path is really used by apache (because the dynamic detection takes precedence), so it is a noop parameter which clutters up the UI. I still suggest removing it.
See last posts in:
https://community.nethserver.org/t/re-improve-reverse-proxy-automatic-handling-of-websockets/15943/16
Yes i saw your point. I’ve no opinion about this but i would be surprised that the dev team would ignore it without a reason. They have always been listening to the community.
There has been many long discussions around this point and by adding my opinion here I fear I’m missing some points…
I agree to remove the WebSocket path input it from the UI, maybe starting from NS 7.9. The reason to keep it is not clear to me. WebTop is already integrated and shouldn’t be used as counterexample.
For other exceptions there are already other ways to configure Apache: e-smith template, drop-in .conf file.
Moreover our UI is not generally designed to satisfy any requirement out there and it shouldn’t provide many complex and technical options. Instead our main target should always be the “one-click” installation of an application. The reverse-proxy feature is secondary to this IMO.
I understand the fear of regressions that could impact existing reverse proxy configurations, so it’s ok for me to keep the “Enable WebSocket” by now. But again, I’d like to hide it in NS 7.9 and set it enabled by default in new reverse-proxy config items.
I thank @carsten for the time he spent on pushing his ideas and the other devs for the time spent on reviewing them 
Please be patient: the Apache configuration is tricky, caution is needed with it.
2 Likes
WebTop is NOT a counterexample, because the “Enable Websocket” checkbox works perfectly with Webtop.
To repeat: The classic way is the configure hard coded ProxyPass statements for apache, which are also a little faster then the dynamic way. The new, dynamic, but somewhat slower way ist the detect Websocket connection on the fly. The big advantage of this is, that there is no extra configuration necessary. It just works (at the cost of some little performance), so it is the perfect solution for a server like Nethserver which should simplify things in the 90% case.
Also keep in mind, that the “already integrated” argument is not the best one in my oppinition, because it is always a good idea to separate the firewall from application server for various reasons (security, maintainability, u.s.), so installing one nethserver for firewall and reverse proxy and one or more for all the application stuff is a good and valid configuration which should be supported from nethserver also, i.e. nethserver should support distributing services to multiple installations of itsself.
As already said, I have an environment, where I have one NS as firewall, IPS, reverse proxy and two other NS servers for webtop, nextcloud, guacamole etc. It works perfectly. The only change needed was the websocket packge and the possibilty to add “flushpackets=on” for guacamole.
I currently try to install a development environment and would try to make the changes myself for publishing.
I understand the fear of regressions that could impact existing reverse proxy configurations
Sorry for repeating: I think it is impossible for a removal impacting existing configurations because the extra rule webpath rule will NEVER be evaluated by apache. This is because the dynamic rule is evalutated first and stops further processing. Maybe someone else should check my conclusion.