I've recently changed my openshift default domain myapp.rhcloud.com in www.myapp.com with a custom ssl certificate. The config works perfectly well until the web page ask the server for a websocket connection. I use node with socket.io and websockets enabled
I first tried:
io.connect(www.myapp.com:8443/...)
But this return an error.
So I set back the socket connection url to:
io.connect(myapp.rhcloud.com:8443/...)
But I get this error:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.myapp.com' is therefore not allowed access.
Is there a way to allow websocket connection via a custom domain on Openshift ? Or, do I need to set up cors?
EDIT
I left socket.io prefix the websocket url I do not pass the protocol to socket.io
From my understanding, WebSockets use something like this (wss instead of ws for secure)
wss://www.yourapp.com:8443
Make sure you setup openshift with your domain alias
https://www.openshift.com/kb/kb-e1096-how-to-setup-an-alias-for-your-application
When I log to https://www.myapp.com:8443/socket.io/1/ in Chrome, I get the error
Identity not verified
which is not the case on https://www.myapp.com... after few tests and searchs I think that this error is due to the websocket preview environnement on openshift. Source (https://www.openshift.com/blogs/paas-websockets):
Update: There is one more known complication. When using our
preview-deployment of WebSockets with HTTPS and WSS protocols, you
will face self-signed certificate. That is because this environment is
only temporary to give you insight into upcoming features. Once we
move the new routing layer to standard ports 80 and 443, i.e. we move
WebSockets support into production, the certificates used will be
signed and valid as they are with current deployment.
Related
I have a working node.js express based server (and client) application here that shows RPC over http+websockets. This works perfectly when run locally (using devcontainers) and includes the Dockerfile as well as devcontainer.json. However, when run from a codespace, it fails with the following client-side error messages.
client.js:9 Mixed Content:
The page at 'https://aniongithub-jsonrpc-bidirectional-example-<redacted>-8080.preview.app.github.dev/'
was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint
'ws://aniongithub-jsonrpc-bidirectional-example-<redacted>-8080.preview.app.github.dev/api'.
This request has been blocked; this endpoint must be available over WSS.
(anonymous) # client.js:9
client.js:9 Uncaught DOMException: Failed to construct 'WebSocket':
An insecure WebSocket connection may not be initiated from a page loaded over HTTPS
at 'https://aniongithub-jsonrpc-bidirectional-example-<redacted>-8080.preview.app.github.dev/client.js:9:10'
The documentation here states that By default, GitHub Codespaces forwards ports using HTTP but you can update any port to use HTTPS, as needed. When I check the settings indicated:
it's set to http. What am I missing here? How can I get it to serve my express application over http?
Note: My intention is that when locally cloned and opened in a devcontainer, the code works just as it would if opened in a CodeSpace. This means I need to ensure that the certs generated by CodeSpaces are somehow factored into my local devcontainer process or that I forego authentication altogether. Alternatively, I need to find out if I'm running on CodeSpaces and do different things, which seems messy and shouldn't be the case. Hope this makes my intentions for asking this question clearer!
It turns out that I just couldn't use http for the RPC endpoint when running over https, so the solution was to use location.protocol and ws/wss depending on the current protocol to initialize the client RPC endpoint.
A web application i developed is sitting on a server that serves it under https, some of my js code requires to open a socket to another server (nodejs) who is currently not set for https. and thus browser wont allow it to run.
all i want is a simple way without getting involved with certificates just to initiate a https socket connection, i don't mind the lack of security,
just need app to run.
The certificates are not your problem. Your problem is CORS. You need to configure your server to answer with a header allows foreign-origin
res.header('Access-Control-Allow-Origin', 'example.com');
because in your case the technical difference between http (port 80) and https (443) is the port.
EDIT: ... I mean from the browsers point of view
I have an SSL enabled Node server (v0.10.35) that provides the user with HTTPS and WSS connections. I would like to add a new SSL enabled WebSocket server to this configuration to allow me to connect a control application to the Node server, ideally using a different URL. For example:
Public Access : https://myserver (via Browser)
Control Access : wss://myserver/control (via my Software)
I am assuming that this can be done but I'll be honest I do not have a clue as to how to configure it, so I would appreciate help from those that do.
I don't know if it is worth while pointing out but my current implementation already supports WS to the Browser, this allows me to (obviously) send and receive messages.
What I would like to do is either add another WS Server to handle the control messages or configure my existing install to have multiple URLs so the browser would default to wss://myserver but the application would use wss://myserver/control for example.
I have a website behind cloudflare. I need to enable websockets over SSL without turning off cloudflare support. I have a PRO plan and hence won't get the new websocket support. I am using Nginx to proxy a SSL connection to a web socket running on a node server. Now, I read somewhere that cloudflare could work with approved ports would support websockets. Hence, I'm using 8443 for the Nginx port and another port for the node server. Using wscat it returns a 200 error.
$ wscat -c wss://xyz.com:8443
error: Error: unexpected server response (200)
I know that the websocket is expecting a 101 code. However, if I visit https://xyz.com:8443, I can see the page displayed by the node server telling me proxy is working. Also, once I turn off cloudflare support, the websocket starts working. Any clues to get this working. I know I can create a subdomain but I'd prefer running the websocket behind cloudflare.
If you're trying to access this through CloudFlare's network you'd need to explicitly have web sockets enabled on your domain before they will work -- regardless of the port. As in, even if the port can pass through our network, that won't automatically mean that web sockets will be enabled or accessible on your domain.
You can try contacting our support team to request an exception to see if they can enable it for your domain, but typically this is still only available at the business and enterprise levels.
Disclaimer: I work at CloudFlare.
I'm trying to create a reverse proxy in NodeJS. But I keep running the issue that in that I can only serve one one set of cert/key pair on the same port(443), even though I want to serve multiple domains. I have done the research and keep running into teh same road block:
A node script that can serve multiple domains secure domain from non-secure local source (http local accessed and served https public)
Let me dynamically server SSL certificates via domain header
Example:
https ://www.someplace.com:443 will pull from http ://thisipaddress:8000 and use the cert and key files for www.someplace.com
https ://www.anotherplace.com:443 will pull from http ://thisipaddress:8080 and use the cert and key files for www.anotherplace.com
ect.
I have looked at using NodeJS's https.createServer(options, [requestListener])
But this method supports just one cert/key pair per port
I can't find a way to dynamically switch certs based on domain header
I can't ask my people to use custom https ports
And I'll run into browse SSL certificate error if I serve the same SSL certificate for multiple domain names, even if it is secure
I looked at node-http-proxy but as far as I can see it has the same limitations
I looked into Apache mod-proxy and nginx but I would rather have something I have more direct control of
If anyone can show me an example of serving multiple secure domains each with their own certificate from the same port number (443) using NodeJS and either https.createServer or node-http-proxy I would be indebted to you.
Let me dynamically server SSL certificates via domain header
There is no domain header so I guess you mean the Host header in the HTTP request.
But, this will not work because
HTTPS is HTTP encapsulated inside SSL
therefore you first have to do your SSL layer (e.g. SSL handshake, which requires the certificates), then comes the HTTP layer
but the Host header is inside the HTTP layer :(
In former times you would need to have a single IP address for each SSL certificate. Current browsers do support SNI (server name indication), which sends the expected target host already inside the SSL layer. It looks like node.js does support this, look for SNICallback.
But, beware that there are still enough libraries out there, which either don't support SNI on the client side at all or where one needs to use it explicitly. But, as long you only want to support browsers this should be ok.
Redbird actually does this very gracefully and not too hard to configure either.
https://github.com/OptimalBits/redbird
Here is the solution you might be looking at,
I found it very useful for my implementation
though you will need to do huge customization to handle domains
node-http-rev proxy:
https://github.com/nodejitsu/node-http-proxy
Bouncy is a good library to do this and has an example of what you are needing.
As Steffen Ullrich says it will depend on the browser support for it
How about creating the SSL servers on different ports and using node-http-proxy as a server on 443 to relay the request based on domain.
You stated you don't want to use nginx for that, and I don't understand why. You can just setup multiple locations for your nginx. Have each of them listen to different hostnames and all on port 443.
Give all of them a proxypass to your nodejs server. To my understanding, that serves all of your requirements and is state of the art.