neo4j-browser
neo4j-browser copied to clipboard
neo4j
New Neo4j browser (3.2.0) cannot connect using HTTPS
After updating to Neo4j 3.2.0 the browser cannot connect to the database using HTTPS instead of Bolt any more. Due to firewall restrictions we're not able to open the Bolt ports to the world to allow web socket connections to the Bolt port directly. Instead we have to use the opened HTTPS ports.
This worked with 3.1.x but with 3.2.0 we cannot find a way to tell the browser to use HTTPS instead of Bold for connecting to the database.
Hi @sgehrig !
Thanks for raising this issue. This is a known regression in Neo4j 3.2 which will be addressed in a patch release. The rewritten Neo4j Browser did not migrate the code for http or https. Instead, the javascript driver itself will be upgraded to provide this functionality.
Apologies, Andreas
@akollegger Is there any release date yet? Oh, and thx for taking care of that issue.
@sgehrig Bolt encryption should still be wrapped within TLS, I believe. So would it work if you set your environment's reverse proxy to forward something like bolt.server.com:443 -> internal-bolt:7687?
@naisanza Yes. A proxy would be an option. But in our setup we'd prefer to have the “old" HTTPS connection back. Nobody here wants to change the setup ;-) (and it's not me who's responsible).
Anyone else who is affected by Neo4j Browser in 3.2 not being able to use http(s) anymore, can you please drop an email with all details (why exactly you need it, for us to collect feedback) to [email protected] to inform the decision process
As a work-around you can replace the browser-jar with one from 3.1.x and it should work.
+1 We've same problem with redirect BOLT protocol traffic (due port restrictions). Please supply a solution to run Neo4J Browser with only ports 80/443.
Also got stuck in this (using the official Docker image). For me it worked to go back to v3.0.9:
Just switched:
FROM neo4j:latest
...
To:
FROM neo4j:3.0.9
...
Of course, not a real "solution" but it got me being able to connect via browser just as before (even with custom self-signed certificates).
Version 3.1.x did not work instantly, yet I did not further investigate that (seemed like the same issue). I rather switched further down to v3.0.9 as I did not need the latest release.
bump. I downgraded from neo4j:latest to neo4j:3.0.9 and it also fixed my SSL connection issues with the browser (which is awesome btw).
@akollegger can you please tell how much more time can we expect for that patch to get released .Now I am using its public version and am planning to use it for my official project and is there any work around for this bug ???
+1 For sure, https is a more friendly protocol for firewalls and reverse proxies than Bolt can be... Stuck in 3.1.4 (we had to tick "dont'use bolt" in the browser side params for each client to work properly).
I'm surprised this is still missing from the 3.2 release. It was a major step backwards in usability when confronted with restricted environments.
same problem. WebAdmin works perfectly with http:// but cant login with https://
This seems to still be an issue in 3.3.0-enterprise. I'm trying to get Neo4j running behind Nginx (handling TLS) and would like to avoid publishing port 7687. But the option to not use bolt is no longer in the browser UI. Any updates on this?
I've the same issue. Also using Nginx reverse proxy to ensure TLS and single sign on.
On Tue, Dec 19, 2017 at 12:21 AM, Kyle W. Rader [email protected] wrote:
This seems to still be an issue in 3.3.0-enterprise. I'm trying to get Neo4j running behind Nginx (handling TLS) and would like to avoid publishing port 7687. Bu the option to not use bolt is no longer in the browser UI. Any updates on this?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/neo4j/neo4j-browser/issues/511#issuecomment-352589504, or mute the thread https://github.com/notifications/unsubscribe-auth/ARsGeLBVqh4Tn3VDt3nrSQBEkEFChfAtks5tBvNggaJpZM4NZGqc .
Any word on the promised patch?
Really stuck needing to make the browser accessible behind a proxy without the need to open other ports.
You might be able to work around this issue on Linux using iptables . I did this with 7474.
For example sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 7687 or sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 7474
https://wiki.jenkins.io/display/JENKINS/Running+Jenkins+on+Port+80+or+443+using+iptables
If you need port 80 to go to 7474 and 7687, the only way I can think of to do that (from the same source ip) is to use port knocking software to give you a way to flip what port the redirect goes to and flip it back.
Note the command to see your prerouting rules is not --> iptables -L
Use --> iptables -L -t nat
Do this at your own risk. Get something in writing from someone who has power to un-fire you if anybody wants to make an example of you for doing this. If you need to do this because you work in a restricted environment the proper route is to submit a port exception request. Sharing this for info purposes only.
If you have three HTTP ports you need to access on a single aws-server. aws-server:8001 aws-server:8002 aws-server:8003
Setup port redirect on aws-server using iptables so that 80 forwards to 8001. sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8001
Setup a new server aws-server2 and install a simple http proxy like the one below. Set it up to listen on port 80. Next, you will need to hack one line of code in this file to always go to port 8002.
https://github.com/abhinavsingh/proxy.py/blob/ea33c0e2c9442a0f331f5171a1293a8aa1ccde95/proxy.py
Based on his github picture, Abhinavsingh seems trustworthy. Use whatever proxy code you prefer.
http://aws-server2 is now the same as http://aws-server:8002. Obviously the traffic won't go directly to aws-server, it goes to aws-server2:80 and then is forwarded to aws-server:8002. The neo4j browser bolt connection HOST line will need to be changed at the log in prompt.
Do similar for fix with aws-server3.
