Https and wss cant connect to api

#1

Spun up an aws ec2 linux instance using bitnami parse server and dashboard ami. Using the public ip over http worked fine but couldnt get live query to connect, cors issue seemed to be the problem and no way to setup an ssl cert without a domain pointing to it.

So I setup my domain on the server using aws application load balancer and setting an SSL cert on it from certificate manager and nothing I did would get it to work over https or wss. I assumed it was an issue with how the load balancer handles ssl cert and went to plan b.

Changed the domain to point directly to the server ip and setup an SSL cert with let’s encrypt and still cant get https to work. Only http works.

I can load the dashboard over https and the cert shows valid and secure so https does work that way, I just cant get the api to connect over https.

I’ve seen a few other posts about this issue but none seem to actually be resolved.

I’ve tinkered around with different versions of the domain in the server url setting using everything from domain to localhost to ip address, nothing seems to work.

The only thing I can think of at this point is this small instance doesnt setup ipv6, only ipv4 but I have a hard time believing that would be the issue.

The security group is setup for https and of course port 1337 is open and it does work over http fine.

What am I missing here? Is there something else I need to add to config.json or something to force everything over https within the app?

#2

It is really hard to help you figure it out unless you share the specific settings you have in each of the components. But have in mind that the Parse Dashboard uses the Parse JS SDK. in order to connect to the API. So, if Parse Dashboard is working, you can use the same server URL in the SDK and it should work as well.

#3

My guess would be the load balancer listener port config, but as Davi already said, there are too many moving parts to know from a distance without further details.

I suggest you take a look at this guide:

#4

I got everything working over https, I’m guessing the problem was a session token mismatch going from one to the other.

However I still get WebSocket connection failed using wss://mydomain.com/parse (or any variation of the domain)

In the parse logs it says:
parse-server running on https://mydomain/parse
info: Parse LiveQuery Server starts running

Here’s my config:
{
“appId”: “myappID”,
“masterKey”: “xxx”,
“appName”: “parse-server”,
“mountPath”: “/parse”,
“port”: “1337”,
“host”: “127.0.0.1”,
“serverURL”: “https://mydomain/parse”,
“databaseURI”: “mongodb://bn_parse:[email protected]:27017/bitnami_parse”,
“cloud”: “/opt/bitnami/cloud/main.js”,
“liveQuery”: {
“classNames”: ["_User","_Role",“TestObject”]
},
“startLiveQueryServer”: “true”,
“liveQueryServerOptions”: {
“appId”: “myappID”,
“serverURL”: “wss://mydomain/parse”,
“masterKey”: “xxx”,
“logLevel”: “VERBOSE”
}
}

Here’s the client side code I’m using with the JS SDK:
Parse.initialize(‘myappID’);
Parse.serverURL = ‘https://mydomain/parse’;

let TestObject = new Parse.Object.extend(‘TestObject’);
let q = new Parse.Query(‘TestObject’);
q.equalTo(‘foo’, ‘bar’);
const results = q.find();
results.then(function(obj) {
console.log(obj);
});

let subscription = q.subscribe();
console.log(subscription);

The query works as expected and gives the results in the console. Then it’s just a bunch of websocket connection failed.

Again, I’m not using the aws loadbalancer and certificate manager ssl, I’m pointing the domain directly at the server IP and using a let’s encrypt ssl cert directly on the server created by the bitnami let’s encrypt tool that came pre-packaged in the ami. HTTPS is working as expected.

Once thing I have noticed though that is no matter what I change the serverUrl value to under liveQueryServerOptions the console error always shows WebSocket connection wss://mydomain/parse failed, even if I remove /parse, change it to the IP address or whatever and then restart parse.

I feel like I’m missing something really obvious and dumb here.

#5

Here’s a bit from my apache access log, the string of 403’s at the end I’m assuming are the wss:// calls
64.xxx.79.xxx - - [03/Aug/2021:17:15:18 +0000] “OPTIONS /parse/classes/TestObject HTTP/1.1” 200 2
64.xxx.79.xxx - - [03/Aug/2021:17:15:18 +0000] “GET /parse HTTP/1.1” 403 24
64.xxx.79.xxx - - [03/Aug/2021:17:15:18 +0000] “POST /parse/classes/TestObject HTTP/1.1” 200 245
64.xxx.79.xxx - - [03/Aug/2021:17:15:18 +0000] “GET /parse HTTP/1.1” 403 24
64.xxx.79.xxx - - [03/Aug/2021:17:15:20 +0000] “OPTIONS /parse/health HTTP/1.1” 200 2
64.xxx.79.xxx - - [03/Aug/2021:17:15:20 +0000] “POST /parse/health HTTP/1.1” 200 15
64.xxx.79.xxx - - [03/Aug/2021:17:15:20 +0000] “GET /parse HTTP/1.1” 403 24
64.xxx.79.xxx - - [03/Aug/2021:17:15:24 +0000] “GET /parse HTTP/1.1” 403 24
64.xxx.79.xxx - - [03/Aug/2021:17:15:34 +0000] “GET /parse HTTP/1.1” 403 24
64.xxx.79.xxx - - [03/Aug/2021:17:15:43 +0000] “GET /parse HTTP/1.1” 403 24
64.xxx.79.xxx - - [03/Aug/2021:17:15:57 +0000] “GET /parse HTTP/1.1” 403 24
64.xxx.79.xxx - - [03/Aug/2021:17:16:13 +0000] “GET /parse HTTP/1.1” 403 24
64.xxx.79.xxx - - [03/Aug/2021:17:16:21 +0000] “GET /parse HTTP/1.1” 403 24

#6

I guess the problem is on your load balancer listeners. Could you share the settings you have?

#7

I’m not running a load balancer on the instance at the moment, have the domain pointed directly at the IP address.

#8

I should also mention that in my Parse log I get the following after starting parse:
info: Parse LiveQuery Server starts running

Which is logged with this:
wss.onListen = () => {
_logger.default.info(‘Parse LiveQuery Server starts running’);
};

As far as I can tell the live query server is starting up and listening. I logged the wss server object to see what that spit out and got the following:

info: Parse LiveQuery Server starts running {“options”:{“appId”:“myappID”,“serverURL”:“wss://mydomain.com/parse”,“masterKey”:“xxx”,“logLevel”:“VERBOSE”,“server”:{"_events":{“connection”:[null,null]},"_eventsCount":5,"_connections":0,"_handle":{“reading”:false},"_usingWorkers":false,"_workers":,"_unref":false,“allowHalfOpen”:true,“pauseOnConnect”:false,“httpAllowHalfOpen”:false,“timeout”:120000,“keepAliveTimeout”:5000,“maxHeadersCount”:null,“headersTimeout”:60000,"_connectionKey":“4:127.0.0.1:1337”}}}

#9

Is it still working via ws but not working via wss?

#10

I can’t get either one to work.

#11

I’d be happy to give you full ssh/login creds for everything here, this is just strictly a test setup to just figure out how to get this all setup and working correctly.

#12

I guess you need to setup something on apache to make the web socket connection to work. This thread may be helpful: Setting up a websocket on Apache? - Stack Overflow

#13

Thanks for the link, that might get me closer, testing some stuff now.

#14

I have all of the apache modules mentioned already installed and tried a few variations in the apache conf but still no joy.

Bitnami is zero help on anything with their AMI’s so who knows. I think tomorrow I’ll try just creating a new server and installing/configuring everything from scratch. At least that way it will be a legit install and not “preconfigured” by someone else with no docs on how they did it lol.

1 Like
#15

Do you use some kind of proxy? When I used Nginx as a proxy, I had to define a header like this:

proxy_set_header Connection "Upgrade"
Without this, websockets wouldn’t work.

In this answer they are doing something similar with apache. Take a look.

#16

I have a hunch it’s something with this specific version of parse in this latest bitnami ami.

My parse-server version says 4.9.3 which I guess was a screw up on tags but also seems to be some issues with this exact problem where wss can’t connect.

See the following upstream:

#17

The latest official version is actually 4.5.0. Could you please try with that one?

#18

Bitnami gave me an older ami with version 4.3.0 in it that I deployed.

Same exact problem. I’m sure it’s something with apache/proxy_wstunnel_module and the reverse proxy configs but nothing I try seems to matter.

I wish there were some type of documentation or better yet, examples of how to config apache to work with the live query server but about all I can find relates only to nginx.

I’ve tried several variations of the following in the apache config:

#RewriteEngine on
#RewriteCond ${HTTP:Upgrade} websocket [NC]
#RewriteCond ${HTTP:Connection} upgrade [NC]
#RewriteRule .* “ws://127.0.0.1:1337/$1” [P,L]

#ProxyPass “/parse” “wss://127.0.0.1:1337/parse”
#ProxyPassReverse “/parse” “wss://127.0.0.1:1337/parse”

I’m pretty much at a loss here at this point, I’ve been beating on this thing for a week now and no closer than I was when I started. Parse is the ideal solution for what I need to build since I can keep it all under the aws infrastructure and I’m unable to use Firebase but without the ability to connect to the live query server with wss it’s worthless to me. I’m pretty much out of ideas at this point.

#19

Maybe you should try to reach out Bitnami to get some help or try to create a server from scratch using nginx and GitHub - parse-community/parse-server-example: Example server using Express and the parse-server modul

#20

I finally got it working.

In the /opt/bitnami/apache/conf/vhosts/parse-https-vhost.conf file I added the following under virtual host:

SSLProxyEngine on RewriteEngine On RewriteCond %{HTTP:Upgrade}
websocket [NC] RewriteRule /(.*) ws://localhost:1337/$1 [P,L]

ProxyPass “/parse” “ws://127.0.0.1:1337/parse” ProxyPassReverse
“/parse” “ws://127.0.0.1:1337/parse”

Whether or not that’s actually secure I have no idea, the live query subscribe call from the client goes over wss:// and it doesn’t give any warnings or errors so I guess I’m good now.

It would be helpful for future users I think if this was added into the docs somewhere. A lot of devs aren’t apache or nginx gurus especially as it relates to websockets, even the guys at bitnami said setting up for websockets was out of their realm of experience.

All that said I’m pretty damn excited to jump in there and start actually building some stuff with this thing now lol.

Thanks for the help!

1 Like