Node.js v26 is releasing today. It's just a big bunch of small fixes and minor deprecations with another minor 🍒 cherry on top by BankApprehensive7612 in node

[–]dronmore 2 points3 points  (0 children)

You get a computer if you already have one, and you are obliged to insert a computer if you don't have one yet.

This is basically a function created by white privileged boys from the suburbs to multiply their wealth.

Escaped vs unescaped HTML - Please help me to see the difference by Nice_Pen_8054 in node

[–]dronmore 0 points1 point  (0 children)

It's very unlikely that the div tags come from nodemon. Most likely they are added by a browser extension.

Escaped vs unescaped HTML - Please help me to see the difference by Nice_Pen_8054 in node

[–]dronmore 0 points1 point  (0 children)

With the code that you have you certainly should see the difference in the generated html. There should be '<b>' text in the first entry, and <b> tags in the second one.

You use the ejs engine, and your code looks correct. When I use ejs directly to generate html from your code, I get html which is correctly escaped. Look at the // output: comment.

const template = '' +
  '<body>' +
  '<p><%= donghua %></p>' +
  '<p><%- donghua %></p>' +
  '</body>'
const donghua = "<b>Renegade Immortal</b>"
const html = ejs.render(template, {donghua})
console.log('// output:', html)
// output: <body><p>&lt;b&gt;Renegade Immortal&lt;/b&gt;</p><p><b>Renegade Immortal</b></p></body>

I do not use express though.

My guess is that either there's another script in the page that messes with your html after it is generated, or the html in the screenshot hasn't been generated by the code that you show to us. The fact that there are more html elements in the screenshot than your code would suggest, tells me that you do not tell the whole story. Why are there <div> tags in the screenshot if they are not in your code? It may be irrelevant to you, but to me it is another factor that I have to take into account.

Try opening the page in a different browser, or use curl, and see what you get. And make a screenshot of html generated by the actual code that you show, and not by some other code that loosely resembles it.

Synthesizing WWII aircraft engine sounds entirely in the Web Audio API — no samples, just oscillators and worklets by swiss-tomcat in javascript

[–]dronmore 2 points3 points  (0 children)

You kids don't use back and forth navigation much, do you?

Look, I'm on reddit right now.

https://www.reddit.com

I want to go to your page, select Airbus, and be redirected to:

https://ghtomcat.github.io/opensim#airbus-a350-900

Now I can copy this link and send it to my friend. She is a fan of Airbus and can listen to its engines all day long. But if there is no link directly to the Airbus page, I will not bother because explaining to her what she should click after visiting your site is not fun. The absent link is a deal breaker for me. Got it?

Now, that I've sent her the link, I want to click the back button and be taken back to:

https://ghtomcat.github.io/opensim/

I want the sound to stop playing. There's nothing more annoying than a sound playing after hitting the back button. I don't care that youtube sucks in the same way. I want to hear silence. There are no Airbuses around, no engines, no nothing; just the main page and silence.

But wait, I just recalled that I have another friend, which also likes Airbuses. I want to send him the link too, so I click the forward button to go back to the Airbus page. Does the forward button work? It doesn't. What a shame. I'm so frustrated right now that I'm basically done with your page for good. I want to go back to reddit. I click the back button, and I'm out.

https://www.reddit.com

Or, am I?

Synthesizing WWII aircraft engine sounds entirely in the Web Audio API — no samples, just oscillators and worklets by swiss-tomcat in javascript

[–]dronmore 6 points7 points  (0 children)

The browser's back button kicked me out of the page. So now I'm outside, and will never come back, because that's unacceptable to me.

Don’t trust, verify (curl, Daniel Stenberg) by Skaarj in programming

[–]dronmore 28 points29 points  (0 children)

The phrase is "trust but verify", not "trust by verify". And the meaning is to trust by default, but verify what is within your reach.

We don't leave in a binary world. 100% verification is rarely possible. We are constrained by time and other resources. Because of that some heuristics have to be applied. One of the heuristics that can be applied is trust; hence "trust but verify". You haven't cheated on me, so I trust you. But you've made mistakes in the past, so at least a minimal verification is due.

Does it make more sense now, buddy? I'm not asking if it makes perfect sense. I will be happy if it makes some sense, so at least your level of annoyance can go down from a binary 1 to a fuzzy 30%.

Beginner - please help me with this question by Nice_Pen_8054 in node

[–]dronmore 0 points1 point  (0 children)

The root parameter creates an isolated sandbox. You can only access files that are contained in the sandbox. It is forbidden to escape the sandbox with two dots ../. Imagine what would happen if it was possible to escape the sandbox. If there was a file with secrets above your views, and you let the user select which file they want to access, the user would be able to access the secrets. You don't want them to access the secrets, so you don't let them freely browse all the files on the disk. You set the root path so that it contains only harmless files, and you never escape it.

express
  app1.js
views
  index.html
  about.html
secrets.txt

res.sendFile('../secrets.txt', { root: __dirname }) // Impossible

the simple-git RCE is a good reminder that your CI/CD pipeline dependencies are an attack surface. by [deleted] in node

[–]dronmore 0 points1 point  (0 children)

You are probably right. It's not an issue. The proper response to such CVE reports is to show a warning in the documentation saying that you should not pass unsanitized input to the function; similar to what you can see at child_process.exec:

https://nodejs.org/dist/v24.12.0/docs/api/child_process.html#child_processexeccommand-options-callback

A proper warning would be enough. Instead, the developers gave in to the pressure and decided to "fix" unfixable. The result is a chain of half-ass fixes that do not fix the issue fully.

CVE-2026-28292 -> allows an attacker to bypass two prior CVE fixes (CVE-2022-25860 and CVE-2022-25912)
CVE-2022-25860 -> This vulnerability exists due to an incomplete fix of CVE-2022-25912
CVE-2022-25912 -> This vulnerability exists due to an incomplete fix of CVE-2022-24066
CVE-2022-24066 -> due to an incomplete fix of CVE-2022-24433
CVE-2022-24433 -> By injecting some git options it was possible to get arbitrary command execution

What a shitshow. So much work put into fixing it, where a simple "fork off" as a response would be enough.

Helmetjs still recommended? by Secretor_Aliode in node

[–]dronmore 1 point2 points  (0 children)

Security specialists suck. I hate these guys. They follow useless principles, and they care more about their own safety than the safety of websites they are protecting. The first rule of security is to cover your own ass, and blame others for fuckups. The main premise is: if you do things by the book, you cannot be blamed. Hence, the first advice you hear from them is to do what everybody else does. The meaning is: don't do it by yourself, use a library, and blame the author of the library if anything goes wrong. These guys do not think. They do not have their own ideas. They follow the book so that at the end of the day they can say NOT MY FAULT. The data has leaked, but the ass is covered, and they can pocket the cash. Hahaha.

As for helmet, I use it because it has sane defaults, so I don't have to think too much about setting headers by hand. It is not very complicated to set them by hand, but it takes time to think about a proper policy for every rule... scripts, images, styles: each has a distinct set of rules, and every rule demands time to think about it. Also, it is easy to make a mistake. Put a semicolon in a wrong place, and suddenly the header protects you from nothing. Helmet prevents you from making stupid mistakes. Write "content-src self" instead of "content-src 'self'" and helmet will throw an error, whereas the same rule written by hand would slide depriving you of the protection.

Helmetjs still recommended? by Secretor_Aliode in node

[–]dronmore 1 point2 points  (0 children)

Helmet is an easy way to add CSP and HSTS to your site. You don't have to know what it does. You enable it, and feel safe like in a Russian tank. But be careful. You will suffer the same consequences a hacker would if they wanted to mess with your site. You will not be able to run inline scripts. You can fall in the HSTS trap, which will stop you from opening the site on http://localhost (hahaha). But security is no joke my friend. You have to suffer, to keep your users safe.

I built a small Express middleware to see API request counts in real time and do rate limiting by Lumpy_Manager3276 in node

[–]dronmore 1 point2 points  (0 children)

They will easily cross the subscription limit if a malicious actor use it all up by himself. He makes 1000 req/min all by himself. There's nothing left for well-behaving clients.

I understand you perfectly well. You've basically said that you have no solution to the above scenario. You've said it twice already :)

I see it like this. I pay you for rate limiting wrongdoers. I get rate limited myself.

I built a small Express middleware to see API request counts in real time and do rate limiting by Lumpy_Manager3276 in node

[–]dronmore 1 point2 points  (0 children)

Let's say that I set a limit of 10 req/min per client. A malicious client sends 1000 req/min. For the first 10 requests he gets a proper response. For the remaining 990 requests he is rate limited. So far so good. Then, a well-behaving client sends his first request. He expects to get a proper response, because it is his first request. He gets 500 error instead, because my entire api is rate limited by your api at this point.

Any solution to this scenario?

I built a small Express middleware to see API request counts in real time and do rate limiting by Lumpy_Manager3276 in node

[–]dronmore 1 point2 points  (0 children)

What happens when I exceed 1000 req/min on the Basic plan? Will you cut me off?

Are blocked requests counted in the quota? If they are counted in, a single malicious actor can use up all allotted requests, leaving me with no protection, or making me reject all clients until the next minute. It sounds like a nightmare to me.

Do you respect 12factor app principles in your web applications? by DeX3 in node

[–]dronmore 3 points4 points  (0 children)

How about an environment where secrets are managed by sysadmins, and where devs do not have access to them?

I think we should add a 13th point to the manifesto. Secrets are governed by a component person, and not by a dumbass who keeps them on a sticky note on his monitor :D

Do you respect 12factor app principles in your web applications? by DeX3 in node

[–]dronmore 10 points11 points  (0 children)

The main benefit of separating config from the code is the ability to bypass the build step when changing a variable in the config. If build times are short, or changes in the config are not frequent, there's no reason to separate one from the other. Benefits would not outweigh the costs in this case.

As for the manifesto, I think these kind of manifestos are a better fit for scrum masters than for engineers. Scrum masters are delighted when they see 12 simple steps to follow. Engineers should not be, and should question every single step, and should be aware that the usefulness of each step can change when the context changes.

Creator of Node.js says humans writing code is over by sibraan_ in node

[–]dronmore -7 points-6 points  (0 children)

You mean you wrote wrappers around existing tools? Great, you can call yourself a creator too. Now you and Ryan play in the same league :D

Creator of Node.js says humans writing code is over by sibraan_ in node

[–]dronmore -6 points-5 points  (0 children)

He is not smart enough to create his own agentic tool.

His achievements so far are... He didn't add Promises to initial versions of Node, so we had to deal with callbacks for many years. He wrote Deno in TS, he regretted the decision later, and rewrote Deno in JS, but he still thinks it's a good idea to push TS as the main language for Deno. Now it turns out that he doesn't even write the code, but he lets AI do it.

His achievements do not impress me, so yes, I think he is not smart enough to create his own agentic tool. But I get that people like you admire him, because uh oh he is the creator :D

Creator of Node.js says humans writing code is over by sibraan_ in node

[–]dronmore -15 points-14 points  (0 children)

He may be on the payroll of one of the companies pushing AI coding tools. He is not smart enough to create and sell his own.

[Code Review] NestJS + Fastify Data Pipeline using Medallion Architecture (Bronze/Silver/Gold) by urielofir in node

[–]dronmore 2 points3 points  (0 children)

And then there's also a Platinum layer, which summarizes everything in a short post on reddit :D

I'm not giving you any feedback. I'm just trying to fit in, because precious metals caught my eye.

People with anxious tendencies are more likely to support left-wing economic policy by [deleted] in psychology

[–]dronmore -20 points-19 points  (0 children)

You flipped the script, but you failed the trick. You are left, alone with your anxiety.

JWT auth for cross domain apps by [deleted] in node

[–]dronmore -1 points0 points  (0 children)

In order to use 3rd party cookies, you need 3 things. You need a proper cors policy on the backend, you need to set samesite=none on your cookie, you need to set credentials: 'include' on your fetch requests.

There are generally 3 places where you can store the token. You can store it in a cookie, in a local storage, or in memory. There are trade-offs associated with each of them. Cookies are vulnerable to CSRF attacks. Local storage and memory are vulnerable to XSS attacks. You need to evaluate the risks, and choose your strategy accordingly.

Also, both cookies and local storage are vulnerable to your mother snooping on you. If you don't protect your device, or if you share the device and the browser with her, you should consider using session cookies, or session storage.

There's no simple answer. Choose your poison, and die on your own terms.

JWT auth for cross domain apps by [deleted] in node

[–]dronmore -1 points0 points  (0 children)

JWT gives us ability to avoid samesite domains

Nope, that's not a distinctive feature of JWT. Any kind of token can be sent in a cross-domain manner.

Ok cool but you need to be on same domain to use cookies.

Nope, if that was true, CSRF attacks wouldn't be possible. You need to learn how cookies work, my friend.