Live data from Hacker News

Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

zeroserver.io

161–170 of 256 posts

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#161
post #44
post #26

> File-system Based Routing: If your code resides in ./api/login.js it's exposed at /api/login" rel="nofollow">http:// /api/login . Inspired by good ol' PHP days. > Auto Dependency Resolution: If a file does require('underscore'), it is automatically installed and resolved. You can always create your own package.json file to install a specific version of a package. This sounds like a security nightmare. EDIT: to be c…

If security is a concern, this is probably a bad choice; this doesn't seem to be advertised as a bulletproof security solution to anything, rather a utility for small little one-off apps that might need _some_ backend functionality. Once you start adding features like file-uploading, youre obviously gonna want to pick a more robust option

>_some_ backend functionality

Famous last words.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#163
post #157

Earlier quoted context omitted.

> That said security-minded people are often inconsiderate and horribly untactful in their approach. That needs to change. You don't need to be overly negative to point out a security issue. Something like, "Cool start, but might want to point out that it's not meant for production!" would be a lot better IMHO. Agreed, and I also agree that maybe it should have a tagline about "not production ready" or even "never pr…

> Agreed, and I also agree that maybe it should have a tagline about "not production ready" or even "never production ready". That's a great idea! It should definitely be implemented. With that said, what do you make of the point that things that are clearly not suitable for production (and sometimes labeled accordingly) have a nasty habit of making their way into production anyway? Do you think it has salience here?…

> With that said, what do you make of the point that things that are clearly not suitable for production (and sometimes labeled accordingly) have a nasty habit of making their way into production anyway? Do you think it has salience here? You're clearly a thoughtful person with your hear in the right place, so I'd very much like to hear your opinion.

I don't think I have a good answer. I'm currently serving a little over 6 million requests a month for a service I never advertised yet some non-zero number of developers copied code from stack overflow or wrote based on my github project to hit an endpoint that was just a demo. Since it was un-authenticated and I didn't notice the traffic until much later I have no good way to shut this down without pulling the rug out from under people. Eventually I will have to but since it's not costing my anything extra really I've left it.

Now I put a warning on it when I noticed the traffic but that was 3 years and 2 million requests less per month ago so...

I guess yes, we, as developers, should be better about putting warnings and the like on our projects but by the same (if not greater) token, people using existing code/services bear the responsibility to vet things they use. I don't know how to fix people to vet stuff better. Hell, I don't know how to make myself do that. That said you take risks every day, you risk your live when you get behind the wheel, you risk security holes when you don't vet code you use or build upon. I've weighed the risks of driving against the rewards and found the risk acceptable. For a lot of software I use I've made the same decision. I just don't have the time and energy to vet everything for myself and timelines and other pressures at work make it equally impossible there.

At what point do you say "Ehh, it's secure enough below this point"?

* npm library with 1000's of dependencies?

* npm library with no dependencies

* npm

* nodejs

* OS

* Hardware

I honestly don't know a consistent/standardized way to handle it.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#164
post #152

Earlier quoted context omitted.

In this case the application also tries to auto-install dependencies, so making it read-only removes one of the stated features. I think this framework hasn't been written with security in mind at all.

Whatever it's doing, it's not writing the packages into the application directory.

If it can write to the applications dependencies isn't that as good as writing to the application?

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#166
post #75
post #26

> File-system Based Routing: If your code resides in ./api/login.js it's exposed at /api/login" rel="nofollow">http:// /api/login . Inspired by good ol' PHP days. > Auto Dependency Resolution: If a file does require('underscore'), it is automatically installed and resolved. You can always create your own package.json file to install a specific version of a package. This sounds like a security nightmare. EDIT: to be c…

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 [...]

Hah. Now that’s a Zero day Zero server exploit. :)

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#167

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.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#168

"Zero configuration" But, you can install express, copy paste the getting started code and be up and running at a similar level in 5 minutes. I...guess I don't understand why I should trade something super simple and easy to use for this additional level of abstraction magic. There is such a thing as too much abstraction.

Try doing the same for React (in the same express project). With SSR enabled :)

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#169

Earlier quoted context omitted.

Expecting a student to learn how to code at all, not to mention code well, from an academic/bootcamp setting, is an expensive fool's errand for anyone that hires them. Programming is not academic. It has more in common with plumbing and carpentry and electrician work: you learn only by doing, and you learn how to do it well by doing with critical supervision from a mentor.

That slight wobble in Earth's orbit we're experiencing, that's Dijkstra rolling in his grave. All joking aside, programming should be treated a lot more like engineering and a lot less like craft. Yes, it does have aspects of both, but neglecting the engineering aspects of it is proving to be increasingly harmful to our end users.

> a lot more like engineering and a lot less like craft

I think the curve of diminishing returns plays an important role. A near hack job will often get you 90% there, in terms of fulfilling what was exactly requested. I don't think this is true for any other skillset. It's so easy to make something featureful and fragile in software. The time and cost above that can be very difficult to justify to customers/management.

In the words of a previous boss, after I pointed out we need more testing, "Everything is working, we'll fix the bugs as they come".

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#170
post #157

Earlier quoted context omitted.

> Agreed, and I also agree that maybe it should have a tagline about "not production ready" or even "never production ready". That's a great idea! It should definitely be implemented. With that said, what do you make of the point that things that are clearly not suitable for production (and sometimes labeled accordingly) have a nasty habit of making their way into production anyway? Do you think it has salience here?…

> With that said, what do you make of the point that things that are clearly not suitable for production (and sometimes labeled accordingly) have a nasty habit of making their way into production anyway? Do you think it has salience here? You're clearly a thoughtful person with your hear in the right place, so I'd very much like to hear your opinion. I don't think I have a good answer. I'm currently serving a little…

As you so correctly and wisely point out, we take all kinds of risks every day. It's an inherent part of life. Yet we also generally accept that things that can be done in a safer way should be when reasonably possible.

At this point I'm leaning towards deprecating the idea that encouragement, positivity, and documentation will lead to developers making good decisions. As you've demonstrated, it's clearly insufficient, and I suspect your experience is an outlier but far from unique.

Increasingly, I think we may have to consider measures to get it right the first time. And we have to be sure our peers do too, because we're all living in the same environment and context. Otherwise, sooner or later, someone who didn't read a warning label is going to try to build a PII-handling business on Zero Server (or similar) and it's going to be a dumpster fire.

I would love a world where friendly encouragement, niceness, and documentation could scaleably do this. Sadly, it's perhaps possible that that world and this one could be slightly different.

Post reply on HN