Access to express in os-js?


#7

I notice I haven’t mentioned certbot (and/or letsencrypt) there, only self-signed certificates for local setups… but I’ll update this article.

The nice thing about certbot is that you can just write a regular HTTP host file and it will convert it to use SSL for you.

I recommend nginx though, because on apache there might be some issues (mentioned in that article).


#8

yep! You mean it will redirect port 80 to port 443? (provided nginx is setup to do this)?

Yeah setting up certbot is very automatic, its lovely.

How about xpra and ssl? getting xpra server to use ssl is easy (you just write the --ssl=on flag), but what about xpra client on os-js, do you need to do anything there? I don’t see why you do? Why did you write in the xpra application git repository’s TODO that you need to do ssl? Can’t you just make the xpra server use ssl, then (as the xpra website states) any tcp connections will go through ssl?


#9

Certbot will take the configuration you made for regular HTTP and set up a redirect + a new configuration with the SSL termination :slight_smile:

Ah, this is because the Xpra protocol has support for encryption, which is a layer below the HTTP/WebSocket.

If you use SSL termination on the webserver, this will pretty much have the same effect.

Edit: Just adding that the encryption support normally applies when you do it over local networks, not the internet.


#10

If you use SSL termination on the webserver, this will pretty much have the same effect.

that makes sense, yet it seems like the xpra client on os-js is independently connecting to a different server (its connecting to the xpra server rather than http://localhost:8000/
in my head this would mean all os-js stuff is encrypted through ssl, but the video data and keyboard clicks streamed in the xpra app wouldn’t be encrypted, so you must need to deal with that separately)

you mean the xpra encryption support(the one under http/websockets)? That’s strange, encryption is encryption, why would it only work on local networks

Edit: ohhh also! is there any advantage to using xpra’s encryption rather than ssl(through tcp)?


#11

Yup. The connection is done via Websockify that is attached to the Xpra server. So the connection is independent of the OS.js server.

Because Xpra is its own protocol, sort of like Remote Desktop. In this case, another layer is slapped on top which is just a regular websocket (not wss).

Edit

Doing the SSL on the webserver is probably faster, because the decryption on Xpra for the browser happens in javascript.

Edit

Doing the encryption on the webserver would require another reverse-proxy for the Xpra server (websockify) though.


#12

The user experience would be better in this approach it seems then. Out of the 2 scenarios: the webserver is underpowered, or the network connection of the client is slow(and if decryption was put on top of that, it would be even slower), I would guess the bigger issue in general would be the latter. Hence less lag should yield for the ssl approach.

I may be wrong here, but it seems that xpra server has a SSL module built into it(using the python openSSL module):
2

Does this mean a reverse proxy is only optional for xpra?


#13

Xpra requires a pretty good connection to be a good experience, especially when most of the stuff happens in JS. There’s a WebWorker in use so that some of the data handling is off-loaded into a separate thread, but it doesn’t really solve all of the issues.

But in any case, doing the encryption on the webserver will always be faster when doing it in this context.

Speaking of all of this, I’m actually working on another method of streaming things via Wayland. Stay tuned for that :wink:

Indeed, but as you can see, the client (which is a native client) is attached over a local network over TCP (which of course could be the internet), not a WebSocket. So if you were to do the same thing but with Websockify you would have to do the decryption in javascript.

If you run the Xpra server without SSL and do it in nginx instead, it would have the same effect, but faster because no JS.


#14

Speaking of all of this, I’m actually working on another method of streaming things via Wayland. Stay tuned for that

I’m aware, excited!

yeah that’s a shame, web browsers are so much more adoptable than native applications.

I just assumed(and was hopeful) that the --ssl=on flag automatically encrypted the tcp for you(and hence the xpra app as it stands would magically be encrypted).

“start a server with TCP and SSL support” does this mean the native app can use tcp, and that tcp will be encrypted? I am aware that the native app uses ws:: rather than tcp:: but I am unaware of what difference that makes to be honest.

great! So just like setting it up for os-js, except using the xpra server instead?


#15

Yeah, I was a bit wrong here. This will encrypt the TCP connection for you, but not the Websocket – this must be handled on the webserver.

However, my point on performance still is valid. When you enable encryption on the Xpra server the client will still have to decrypt all of the packets – which is super expensive in JS.

Yeah, same thing, different port :slight_smile:


#16

yeah f*** that then hahaha.

Thanks andersevenrud for the helpful pointers, you’re the man!


#17

And also encrypt them on the way out again.

Any time!

I’ve opened an issue on things that came up in this discussion btw: https://github.com/os-js/manual.os-js.org/issues/14


#18

great, could you send me a link to it? :slight_smile:


#19

Hm. I thought it was linked in my comment.

Trying again:


#20

may I suggest you just remove the /15 at the end of that link? that way people may be less confused.


#21

I used the link to this thread, not the github issue in my comment :man_facepalming:

Updated


#22

hahaha, timezone starting to catch up.


#23

Indeed. I’m getting ready to get to bed :stuck_out_tongue:


#24

I updated the manual with more information on this:

https://manual.os-js.org/v3/tutorial/express/

(Please not that this webserver chaches stuff heavily, so if you don’t see it stay tuned or clear your cache).


#25

great! Yeah that’s a lot more information.

I once did Osjs.app.use(…)

I had to restart npm run serve & npm run watch for it to work. Is this because of caching?


#26

Since I had to restore a snapshot of this server, my original comment was lost – so I’ll try to recreate it.


Restarting the server is enough. When you change the server files this is required.