Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Node.js Patterns

kashw1n.com

Post reply on HN
Print view View original

301–310 of 448 posts

Re: Modern Node.js Patterns

#301

Post by kaoD »

cluckindan wrote: post #160
kaoD wrote: post #115

Earlier quoted context omitted.

This didn't feel right so I went and tested. process.on("uncaughException", (e) => { console.log("uncaughException", e); }); try { const r = await Promise.all([ Promise.reject(new Error('1')), new Promise((resolve, reject) => { setTimeout(() => reject(new Error('2'), 1000)); }), ]); console.log("r", r); } catch (e) { console.log("catch", e); } setTimeout(() => { console.log("setTimeout"); }, 2000); Produces: alvaro@D…

Typo? ”uncaughException”

Oops, thanks! Should've seen the default handler anyways if it was really uncaught.

Re: Modern Node.js Patterns

#302

Post by 01HNNWZ0MV43FF »

Deestan wrote: post #276
Cthulhu_ wrote: post #269

Earlier quoted context omitted.

How would you do this in a native fashion? I mean I believe you (chroot jail I think it was?), but not everyone runs on *nix systems, and perhaps more importantly, not all Node developers know or want to know much about the underlying operating system. Which is to their detriment, of course, but a lot of people are "stuck" in their ecosystem. This is arguably even worse in the Java ecosystem, but it's considered a se…

> but not everyone runs on *nix systems Meaning Windows? It also has file system permissons on an OS level that are well-tested and reliable. > not all Node developers know or want to know much about the underlying operating system Thing is, they are likely to not feel up for understanding this feature either, nor write their code to play well with it. And if they at some point do want to take system permissions seri…

I didn't know Windows has that feature, someone please explain

Re: Modern Node.js Patterns

#303

Post by kaoD »

panzi wrote: post #165
kaoD wrote: post #115

Earlier quoted context omitted.

This didn't feel right so I went and tested. process.on("uncaughException", (e) => { console.log("uncaughException", e); }); try { const r = await Promise.all([ Promise.reject(new Error('1')), new Promise((resolve, reject) => { setTimeout(() => reject(new Error('2'), 1000)); }), ]); console.log("r", r); } catch (e) { console.log("catch", e); } setTimeout(() => { console.log("setTimeout"); }, 2000); Produces: alvaro@D…

So they did change it! Good. I definitely had a crash like that a long time ago, and you can find multiple articles describing that behavior. It was existing for quite a time, so I didn't think that is something they would fix so I didn't keep track of it.

Perhaps you're confusing it with something else? I tried down to Node 8 (2017) and the behavior is still the same.

Maybe a bug in userspace promises like Bluebird? Or an older Node where promises were still experimental?

I love a good mystery!

Re: Modern Node.js Patterns

#304

Post by hk1337 »

berkes wrote: post #242
simonw wrote: post #113

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

I very much dislike such features in a runtime or app. The "proper" place to solve this, is in the OS. Where it has been solved, including all the inevitable corner cases, already. Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?

> The "proper" place to solve this, is in the OS.

This is my thought on using dotenv libraries. The app shouldn’t have to load environment variables, only read them. Using a dotenv function/plugin like in omz is far more preferable.

Re: Modern Node.js Patterns

#305

Post by tracker1 »

Deestan wrote: post #276
Cthulhu_ wrote: post #269

Earlier quoted context omitted.

How would you do this in a native fashion? I mean I believe you (chroot jail I think it was?), but not everyone runs on *nix systems, and perhaps more importantly, not all Node developers know or want to know much about the underlying operating system. Which is to their detriment, of course, but a lot of people are "stuck" in their ecosystem. This is arguably even worse in the Java ecosystem, but it's considered a se…

> but not everyone runs on *nix systems Meaning Windows? It also has file system permissons on an OS level that are well-tested and reliable. > not all Node developers know or want to know much about the underlying operating system Thing is, they are likely to not feel up for understanding this feature either, nor write their code to play well with it. And if they at some point do want to take system permissions seri…

So a separate user for every application I run?

Just locally, that seems like a huge pain in the ass... At least you can suggest containers which has an easier interface around it generally speaking.

Re: Modern Node.js Patterns

#306

Post by tracker1 »

tankenmate wrote: post #221
simonw wrote: post #113

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

I wouldn't trust it to be done right. It's like a bank trusting that all their customers will do the right thing. If you want MAC (as opposed to DAC), do it in the kernel like it's supposed to be; use apparmor or selinux. And both of those methods will allow you to control way more than just which files you can read / write.

Just because you have a safe doesn't mean the lock on the front door is useless.

Re: Modern Node.js Patterns

#307

Post by Etheryte »

berkes wrote: post #242
simonw wrote: post #113

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

I very much dislike such features in a runtime or app. The "proper" place to solve this, is in the OS. Where it has been solved, including all the inevitable corner cases, already. Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?

This is a nice idea, but what do you do when the OS tooling is not that good? macOS is a good example, they have OS level sandboxing [0], but the docs are practically nonexistent and the only way to figure it out is to read a bunch of blog posts by people who struggled with it before you. Baking it into Node means that at least theoretically you get the same thing out of the box on every OS.

[0] https://www.karltarvas.com/macos-app-sandboxing-via-sandbox-...

Re: Modern Node.js Patterns

#308

Post by CSSer »

pests wrote: post #216
CSSer wrote: post #210

Earlier quoted context omitted.

You can get download progress with fetch. You can't get upload progress. Edit: Actually, you can even get upload progress, but the implementation seems fraught due to scant documentation. You may be better off using XMLHttpRequest for that. I'm going to try a simple implementation now. This has piqued my curiosity.

Sniped

Mainly by the fact that all the LLMs were saying it's not possible in addition to GP, and I just couldn't believe that was true...

Re: Modern Node.js Patterns

#309

Post by mcv »

thewisenerd wrote: post #123
mcv wrote: post #107

Earlier quoted context omitted.

This is all very good news. I just got an alert about a vulnerability in a dependency of axios (it's an older project). Getting rid of these dependencies is a much more attractive solution than merely upgrading them.

isn't upgrading node going to ba bigger challenge? (if you're on a node version that's no longer receiving maintenance)

No idea how much compatibility breakage there is, but it's probably going to have to happen at some point, and reducing dependencies sounds worth it to me.

Re: Modern Node.js Patterns

#310

Post by kijin »

arccy wrote: post #293
kijin wrote: post #215

Earlier quoted context omitted.

Path restrictions look simple, but they're very difficult to implement correctly. PHP used to have (actually, still has) an "open_basedir" setting to restrict where a script could read or write, but people found out a number of ways to bypass that using symlinks and other shenanigans. It took a while for the devs to fix the known loopholes. Looks like node has been going through a similar process in the last couple o…

I believe that the various OSes have implemented appropriate syscalls such as openat to support it e.x. https://go.dev/blog/osroot

Even that doesn't protect you from bind mounts. The rationale seems to be that only root can create bind mounts. But guess what, unprivileged users can also create all sorts of crazy mounts with fuse.

The whole idea of a hierarchical directory structure is an illusion. There can be all sorts of cross-links and even circular references.

Post reply on HN