211–220 of 256 posts
Earlier quoted context omitted.
You also need to report this to security@npmjs.com so they post an advisory [1] and mark the existing versions as vulnerable. [1] - https://www.npmjs.com/advisories
Anyone, including yourself can do that.
That's pretty cool to quickly put together a POC app. There should be an "eject" command that would export everything to a "real" Node application, with package.json and so on, so that the POC can be converted to a real app easily.
Check out Reframe: https://github.com/reframejs/reframe It's a web framework like Zero Server and Next.js but everything is ejectable.
It's a web framework with a well-thought-out architecture that you don't need to "eject" from.
Zero configuration... read "We made choices for you, just trust us. Read our documentation to see what your missing. Oh, also since you didn't configure it we'll change (the defaults) on our next release".
> Oh, also since you didn't configure it we'll change (the defaults) on our next release That doesn't really matter, since I'll only use the next release for my next release, and the previous prototype has either been thrown away or turned into a proper stack.
Current app is EOL Framework Release in an EOL Language Release running on an EOL Distro Release on an unmonitored server without any patches applied... so business as usual.
Looking through the code on github found a .py file handler in the works: https://github.com/remoteinterview/zero/blob/master/packages... Any idea of a timeline on this feature? I think it could be really awesome to be able to prototype with python in addition to js.
The js part (React, MDX, Node) is almost complete. I will put out a basic handler for python ASAP if that's going to be useful to you :)
Earlier quoted context omitted.
Standing on the shoulders of giants :) You will eventually be adding all those packages when you develop a production-grade React / Node app anyway.
Perhaps this should be done gradually and thoughtfully, rather than pulling half the internet into each minimalist app out there.
Earlier quoted context omitted.
Putting my money where my mouth is - use this to leak any file accessible by the running user of zero from the filesystem: # curl -v --path-as-is 127.0.0.1:3000/../../../../../etc/passwd root:x:0:0:root:/root:/bin/bash [...]
I don't think I would use any package that makes this classic mistake in 2019. Web services need to be at least vaguely secure and this destroys all my confidence of that.
Earlier quoted context omitted.
Some might imagine it as eschewing heedless amateurism in favor of mature professionalism. One starting point might be re-examining if all the negativity shown in reaction to Zero Server is actually excessive. Some of it surely is! It's also perhaps possible that some of it could be viewed as the horrified reactions of professionals who care about quality (and think about downstream effects) coming face-to-face with…
> Some might imagine it as eschewing heedless amateurism in favor of mature professionalism. I don't fully understand what you're advocating, so I apologize if I am misinterpreting or mischaracterizing your position. But I can't imagine "mature professionalism" including berating or embarrassing another developer for creating a security hole. Some people do need that, but most don't. Many devs I've worked with are ho…
One issue is that full-throated encouragement coupled with suggestions of problems couched in uncertainty is the Dale Carnegie approach. I suspect you're using it now! It's well-suited to a great many situations, as documented in the man's seminal work.
Unfortunately, this suitability is not universal. It is fallible, and in security those failure can be quite dangerous. The Carnegie approach thus described makes it very easy for devs to notice the encouragement and ignore the suggestions of criticism. I have personally encountered this reaction in both open source and enterprise-y contexts, generally from developers who might be charitably described as highly enthusiastic. Including right here on HN!
I've also encountered the hostility you described in reaction to kind, generous, compassionate security reports of the sort you suggest. This has happened in open source, startup-type, and enterprise-y environments.
The key to what I'm advocating is this: you are not your code and the other person is not their code. Who wrote a vulnerability is not as important as that it exists. How it can be fixed, and how it can be prevented in the future, are what matter.
Professionalism means understanding the distinction between a craftsperson and what they have produced. It also means understanding the distinction between yourself and your work. It means understanding that ignorance isn't a character flaw, it's a temporary state of affairs that can be fixed.
It also means realizing that some who refuses to participate in fixing their technical ignorance is someone who is being unprofessional. Such a person might benefit from correction.
Earlier quoted context omitted.
No, you cannot, not in an easy way. I've taught many people Node.js/express and they always struggle with all of those copy/pasted configuration bits. Now if I add them, I tell them something along the lines This is just magic, copy/paste it to make your app work. Some day you will understand . Once you get used to them it's easy, but to get started it's a nightmare. I started with PHP back in the day, and even thoug…
That feeling of discomfort and tinge of frustration means you're learning. I feel like this is helping people to skip over a really useful lesson.
Earlier quoted context omitted.
I don't think I would use any package that makes this classic mistake in 2019. Web services need to be at least vaguely secure and this destroys all my confidence of that.
You would've thought OP posting to HN should've considered security backlash. Unfortunately, damage is done for me too.
This project is brand new, I posted the repo publicly this morning. I frankly think this subthread is an overreaction. I don’t get the hate.
I did something very similar but arguably with even less configuration, https://serverjs.io/ const server = require('server'); server(() => "Place your Node.js API here."); However my project doesn't have the automatic routing/installing/React, which looks great! Keep it up, I like the direction where this is going.