I've fiddled around a lot with cljs + three.js. if you can give me a repro-repo I can help you 🙂

thanks @UCG86LJFN this is not open source at the moment. anyway, you might be able to help me with it. Able to fix the files in /jsm to require three as a module instead of path, but they also import a lot of stuff from three that now hasn't been exported. How do I resolve that, any idea?

just for completeness, the issue was that shadow compiler doesn't ES6 style module imports, i.e.

import {
 Vector2
} from "three";

import * as three from 'three';
const { Vector2 } = three;

seems strange to me. I've been able to do import { Vector2 } from "three". either way, nice that you fixed it 🙂

sorry if this is a dumb question, if it is listening on localhost rather than 0.0.0.0 how is it being exposed ?

it is listening on 0.0.0.0 by default

you can change set by setting :http {:host "localhost"} in shadow-cljs.edn

but it is likely a good idea to run a local firewall?

I think I may add a basic "trusted" check. so that some operation are only allowed from trusted clients. basically an IP check. defaulting to local only but maybe letting you add IPs via config

making those per OP is a bit overkill though

Mm, honestly even just having a configuration flag to turn off all of the ‘trusted’ operations would be super welcome.

But IP whitelisting would make it super effective (again, just across all trusted ops) — I could still get in to debug but allow others to see and hot reload it.

Let me know if I can help at all.

well as soon as you port forword the IP check will fail because the IP will be whatever does the tunneling 😛

Haha I did think of that and wonder (given that your TCP termination would be local) — and then wrote it off without considering further.

but hot-reloading is separate from that anyways

A cookie could work, perhaps? Trying not to create work. 😅

You already have ‘secret’ set, IIRC

the UI stuff already uses a cookie but anyone visiting the UI can get that cookie

Ah and it’s the same for every client?

If it were stored locally, we could whitelist it from the server side

there is not "login" so yeah

If it were unique per client

Just a UUID

nah the secret is just a basic check so that you can't open the websocket without opening the UI first

really basic security check really

I guess I could kill the HTTP side of the channel and only allow HTTP 101 to secure it 😂 — though I suspect it’s sent early :P

But more seriously

first of all you need to separate what you want to allow access to in the first place

hot-reload has nothing to do with any of the UI parts

so blocking the UI is probably good enough

Isn’t it over WS on the same port though?

yes, but it doesn't have to be

Hm

Would cljs REPL also be on the same WS?

Because if there were three ports

ok a bit of terminology so we understand each other

runtime: anything running JS (eg. browser)

tool: anything sending tool command (eg. eval)

relay: shadow-cljs server

access to the relay is open so you can open a runtime anywhere

ie. multiple browser, devices etc

tool connections should probably be restricted somehow

the compiled code is NOT a tool, it is only a runtime

so there need to be no "security" there imho

Got it

restricting the tool access based on IP is easy

it also doesn't need to run on :9630

just currently does for (my) convenience

Right, so three ports would be ideal from my point of view

As in — 3000, 9630 are forwarded

The third port I could just not forward

And that would work perfectly from my POV

People could access the site and runtime but not tool

And the runtime has hot reload and the connection to the relay for cljs REPL into those clients IIUC

Does that seem correct?

And thank you for taking the time to talk

well as soon as the tool access is restricted the UI might as well be too

since it won't work without it

I'll see if I can figure something out

given the fact that all human friendly distro default /etc/hosts to forward to localhost, then I wouldn't worry about defaulting to it. The people that have changed it (hopefully) know what they are doing and I guess could configure their setup differently.

it sounds fine to me too

I vote secure default

for chrome we have an example here, not sure if it is little or particulary nice tough 🙂

https://github.com/binaryage/chromex/tree/master/examples/shadow

Thanks 🙂 Do you think it works with firefox as well?

100% doen’t actually I have no idea

I think firefox extensions are somewhat similar so it might work

the :chrome-extension target actually doesn't do anything chrome specific so it might work

Thanks. I will give it a try

So, i gave it a try today: • built the example using shadow-cljs • loaded the extension in chrome: worked • loaded the extension in firefox: worked with some warnings