Access to express in os-js?


I’m currently trying to give os-js ssl encryption(using an ssl certificate) to do that I need access to app, and express objects:

express = require('express');
app = express();

specifically I need to use the app.use function:

app.use([express.static('static'), require('helmet')());

the documentation does have a piece on this topic, yet its limited to routes. I can’t seem to get enough out of the documentation to fully grasp how to do this correctly.

How would one do this in os-js?


Firstly, you should use a webserver with a reverse-proxy to terminate your SSL – not the node/express server.

This way you can host on regular http/80 and https/443.

But if you really need to do this, you can just do:

const osjs = new Core()

or with any the init event:

osjs.on('init', () =>;

For routes however, you need to use the started event because these are set last!

osjs.on('started', () =>'url', () => {}))


You can also use a service provider for this FYI


thanks for the suggestion! I’ve dived down the nginx rabbit hole now, I’m getting a letsencrypt certificate error now, but I can see the light ahead using this approach.




oh shit! Thanks! :grinning:


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).


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?


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.


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)?


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).


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


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


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):

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


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.


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?


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:


yeah f*** that then hahaha.

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


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:


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


Hm. I thought it was linked in my comment.

Trying again:


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