> 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 clear, I don't meant he combination of both is a security concern, that each one of them separately is problematic.
# curl -v --path-as-is 127.0.0.1:3000/../../../../../etc/passwd
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.
Due to PHP experience, this would've been something that I ensured was implemented properly from the outset. I know this to be true, because I've dabbled in the very space you're working in now, and it was one of the very first things I ensured: that no file could be served except from direct descendants. (I rethought my project and tossed the code)
For something like this you need to be absolutely sure about security. Have a look at the annals of PHP security issues - and most likely you'll see a lot of similarities that you'll need to make sure you address.
I'm sorry if you read hate in my words: definitely was NOT intended! I have nothing against you as a co-habitor of this wonderful planet! To me, the bug highlights that a few design considerations may have been overlooked.
Are you implying that you don’t think it’s ready for production use? If so, maybe you should do like a lot of projects, and warn about it loud and clear in the docs. It’s not clear at all that users should expect the type of blatant security problems that were discovered here.
People are allowed to screw up: it's how we learn. They got comments that pointed out flaws, they fixed them and posted a follow-up regarding that fix, why the hate? This person tried to make something cool, they learned important security lessons, and now have a deeper insight into what they made, and the world it operates in. How is this possibly a bad thing we don't want to have happen on HN?
 - https://www.npmjs.com/advisories
The moment I can upload files to the application folder that are executed, I can just `require('child_process').spawn("my_evil_stuff", )`. In particular "my_evil_stuff" could be some npm install command. I don't see how automatically installing the dependencies makes this worse than it already is.
EDIT: While this is a different attack vector than I was envisioning here, jexco has provided a scenario in which there are additional vulnerabilities: Vulnerable dependencies that cannot be managed.
At the risk of being presumptuous... When is security ever not a concern?
> small little one-off apps that might need _some_ backend functionality
The security implications of serving a static website vs. a dynamic application that processes payment and queries the database are two different beasts
If security is taught at the student level, by the time they get to junior developer they'll have an understanding of it / do it automatically.
When I was a hiring manager and scoped out juniors from bootcamps I had a conversation with some candidates and they would say, "I built user registration and login". When I asked them to talk more about it they said, "well I installed auth0"... Any student project which doesn't teach them how something works is not really teaching anything of value, is it?
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.
Software development (and a lot of hardware development, to be fair) is unique in that doing it well requires functioning as both an engineer and a tradesperson. One's skill has to cover a wide section of the spectrum.
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.
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".
Not everything runs online connected to the internet.
Internal applications where the entirety of the userbase are trusted employees. (Preferably, the userbase is small, too.)
Nobody’s going to bother finding vulnerabilities in an application where, if they break it, their own job gets harder.
Your sort of thinking is how you end up with Yahoo levels of account leaks.
Security always matters.
> Your sort of thinking is how you end up with Yahoo levels of account leaks.
I wouldn’t store any of my customers’ data on an insecure internal service! I know that’s mad!
> Security always matters.
The first part of securing a system is to come up with your threat model, isn’t it?
I'm completely sure that you're right. You know that would be irresponsible and reckless with lots of very sensitive data.
With that said, how sure can you be of every other person writing a simple, small, business app for just a handful of their coworkers? I've encountered some people doing exactly what you've described without the same level of cool-headed risk-weighing as you.
Famous last words.
And auto-dependency resolution also doesn't seem any larger a security concern, all it's doing is skipping an "npm install" command.
And as for automatic dependency resolution, this means you're not even aware of what transitive dependencies you're pulling in, what version they are and have no way to vet anything - everything is hidden behind a wall of magic.
Automatic dependency resolution however... Fantastic for experimentation, but that's a dealbreaker for production. Maybe it would be OK if it actually wrote the package-lock.json to the application directory, I'd have to think about that.
I think this framework hasn't been written with security in mind at all.
For instance, Rails has a public/ folder for files that are going to be served. And jekyll hides files by pattern-matching them.
Zero doesn't seem to have exclude folders by default. The solution would be to run Zero is a subfoler and require file in the parent folder which would act as the tree's root.
By this time it's already too late.
Some classes of bugs that would be otherwise tame due to the constraints (eg., file upload that might be able to only create new files in some part of the directory tree, or a buggy routine that lets you create arbitrary symlinks, or leftover VCS/CM files that happen to end in .js and are not filtered out by the router) now become the most powerful kind, remote code execution.
I could add `require('foo')` but I could also just require no third party code and have fun with the `process` module.
Custom file watcher: https://github.com/remoteinterview/zero/blob/72ea1faaef51b92...
Routing / workers: https://github.com/remoteinterview/zero/blob/72ea1faaef51b92...
Dependencies for using the react renderer: https://github.com/remoteinterview/zero/blob/72ea1faaef51b92...
And so on. The routing part is a bit funny - by spawning a new process per request this is actually very close to PHP/CGI :)
In that vein do you think TypeScript is on the horizon for support? It's not a dealbreaker by any means but it would be nice to just write .ts files and have them automatically compiled (transpiled?). I can write JS just fine but TS's types are a nice sanity check for me.
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.
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 though it's hated around here the bar to getting started there is amazingly low in a good way.
I also teach sometimes and all this friction to get started just makes it harder to get into web development these days.
I prefer those who are new to any webdev to get started by creating a simple CRUD, not with the grunt details like parsing a JSON body or what is this session stuff. Those IMHO should be optional optimization details to apply later on if you wish, but not mandatory for everyone.
There is a reason why frameworks such as Next.js, Reframe, and now this one are being used.
I'd actually say the opposite, it's tools like Webpack that don't have enough abstraction. I don't care how source maps are being generated, why on earth is it a good idea for Webpack to force me to dig into that? (If at least Webpack's default source map config would work out of the box but it doesn't.)
Parcel hits the right abstraction level much better.
Disclaimer: I'm Reframe's author (https://github.com/reframejs/reframe).
Every (web) technology will eventually be called a PHP reinvention.
But I read it so often in the last years.
AWS Lambda? PHP!
I guess my question is: can I trust Zero to always strive for optimum efficiency, or is it just convenience?
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.
const server = require('server');
server(() => "Place your Node.js API here.");
That said, it looks like the latest (not yet npm-published?) version of zero has moved all the dependencies to `devDependencies`.
You will eventually be adding all those packages when you develop a production-grade React / Node app anyway.
node includes not everything and concentrate on the core. If modules have bugs, not all apps a compromised.
It is a fundamental design decision, if you not like it, don't use node.
You can include all dependencies manually and update them manually, nobody keeps you away. But have fun to update all your deps.
Maybe if you listen too much to twitter "thought leaders" you might get this impression, but we are all aware of the problems with social media platforms...
In this example, it is the complexity of this file and the fact that if you were to write this as a single express middleware you could probably write it in less than 20 lines.
Guess this is just not my cup of tea?
Edit: also looks like the author decided to wrap their own multi process model? https://github.com/remoteinterview/zero/blob/master/packages...
But the Frontend with webpack needs definitely more time, hours and hours to fiddle webpack to your needs.
This project has a definded strucutre and support defined modules (react), so it could save you a lot of webpack config time, but you can not do everything with it. You have to use it as it is.
Only get them running is a thing of 2 minutes, but running with comfort and fit your needs is the hard part.
It is nothing wrong with the tool, the tool does what it does. I sayd to configure it, to fit exactly your needs, it take a long time.
Using an other tool will not change it.
Lastly this has so many upvotes and is #1 on the front page because it's cool, fun, and perfect for a little prototype or POC. There are a number of positive comments buried at the bottom but the highest comment is about how this is a "Security Nightmare".
Edit: Typo and I wanted to add: Not everything posted on HN has to be battle-tested, scalable, parallelizable, profitable, cloud-ready, secure, etc. It's the kind of attitude in this thread that keeps people from posting their own work at all. No one want's to get torn apart, back off and provide constructive criticism or keep quiet. (Note: advice I have not always practiced in the past)
Edit 2: Show HN rules (https://news.ycombinator.com/showhn.html), I think this makes my point better than I can.
> Show HN is a way to share something that you've made on Hacker News.
The current Show HNs can be found via show in the top bar, and the newest are here. To post one, simply submit a story whose title begins with "Show HN".
What to Submit
> Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.
> A Show HN needn't be complicated or look slick. The community is comfortable with work that's at an early stage.
> If your work isn't ready for people to try out yet, please don't do a Show HN. Once it's ready, come back and do it then.
> Blog posts, sign-up pages, and fundraisers can't be tried out, so they can't be Show HNs.
> New features and upgrades ("Foo 1.3.1 is out") generally aren't substantive enough to be Show HNs. A major overhaul is probably ok.
> Be respectful. Anyone sharing work is making a contribution, however modest.
> Ask questions out of curiosity. Don't cross-examine.
> Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more.
> When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.
There's already a cultural anti-pattern in the js world of just `npm install`ing stuff and shipping to prod without auditing well (I've heard a number of times, "well it has like 60 stars on github").
If the project marketed itself as a "development only" or non-production framework then I'd agree with you 100%. However as it stands it's dangerous and could lead to extreme compromise of a system if it gets deployed to a production environment.
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 production ready". Not sure what the end goals of Zero are. I will say I thought it was pretty evident that this was not for production (if only to the sheer amount of "magic" inside) but maybe that's just me and it should have a disclaimer to that effect.
Devs need to change their culture. This behavior is actively harming end-users through repeated data breaches.
This isn't new, and not knowing how to deal with it is like a builder not knowing how to safely stand up a wall.
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? You're clearly a thoughtful person with your hear in the right place, so I'd very much like to hear your opinion.
Again, your point is both completely valid and absolutely correct. Purpose and labeling should be clear enough that no person could possibly miss them.
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
I honestly don't know a consistent/standardized way to handle it.
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.
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 reckless engineering.
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 horrified when they find out they wrote in a vulnerability, and they try to grow and find out better ways. This is startup culture tho.
When I worked in enterprise type environments it was the opposite. There, you could send the dev a working exploit and most of them would groan and bitch about how "you security guys just want to tear things down and break things." I can understand being more of a dick in those situations, but I would still contend that's a venting of frustration more than a desire to actually teach. Most people just get defensive and put up walls when they feel attacked or embarrassed, and the learning is over at that point.
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.
> The Carnegie approach thus described makes it very easy for devs to notice the encouragement and ignore the suggestions of criticism.
This is definitely true, I've seen it too. Definitely something to watch out for.
I guess at the end of the day I think it comes down to "know your audience." Similar to the Principle of Least Privilege I like to follow (what I call) the Principle of Least Criticism. Don't use any more criticism than what is necessary, but (and I suspect this is where we will both agree) you need to use enough criticism that the person understands your point.
With that said there might be some significant limitations on the approach. The principle one is that it relies on knowing the individuals involved fairly well. This is easy in a close-knit and small startup environment! It could perhaps be more difficult in a sizable enterprise or open source context where you don't know the other party, don't have time to build a relationship, and/or can't rely on a long conversation to slowly build up to the least amount of criticism required. There's also the question of how to handle groups or meetings in which different people have different thresholds. When one person's minimum required might be someone else's excessive negativity and they're both in the room, there might not be a winning outcome with this approach.
Knowing your audience is an excellent and wise maxim to live by. It might not always be as simple to live by as could be hoped.
Thanks for the discussion
That's a wonderful idea! I'm absolutely certain that people will invariably respond quickly and reasonably to kind, compassionate, considerately made points. Especially ones that are very cautious to cough anything that might be taken as negative as a potential or a possibility.
For my own part, I've found this practice to be both exhausting to implement and highly unreliable in deployment. I'm absolutely certain that these just reflect my own failures. I'm similarly sure that you've seen infinitely better results!
After all, everyone knows that casually documenting something to the tune of "This code might not be as safe for production as it could be" will yield a reasonable level of caution in all developers.
I've also been part of many open source projects and it's very common to not release/announce it until we've proven it ourselves in production.
So while I think one should definitely exercise caution with brand spanking new code, there's no way to know whether it was just ideated recently or has been in development for a while but just got released/opened for the first time.
All those concerns are very valid and will be addressed one-by-one. The project is open source under a decent license, I am VERY willing to accept any security PRs.
That's most of HN these days, and why I never visit anymore.
I don't claim not to visit here.
In this case, the project is clearly too new/unstable/insecure to use in any real sense. It's presence as #1 on HN says more about the audience than the project itself I think.
This is an open-sourcing of, presumably, an internal tool used at CodeInterview. It's "shiny marketing site" feels very cookie-cutter to me and I'd be shocked if that wasn't either a template or a very few handful of components from something like bootstrap/similar. And it was posted to "Show HN", which is important given the rules of Show HN .
> In Comments
Maybe at a glance that is a laudable goal, but surely there is a point where, if you need so much handholding, you should consider either sitting down and learning what you need or making someone else is build it for you.
Newbies? I guess that is possible, but I personally think that actually learning to use your tools and the libraries that are available should be the goal. Handing the control of everything to some 3rd party component is eventually going to leave the beginner with issues they have no way of solving because they've never had to learn anything.
This might seem silly if all you're use to is working on some startup's big app with a dozen other people, but for small orgs that need to run small programs for a long time it's a mess to maintain that stuff over the long term and to count on lone coders in small engagements to get right.
> Handing the control of everything to some 3rd party component
In the cases I describe, this ^^ is a great idea. Keeps maintenance of the common stuff in a common place. Everyone freaked out in this thread about there being a way to get at files outside the project root. Well the author fixed that in one place and now it's fixed for everyone. How many times does an error like that come up and go undetected and uncorrected when even an experienced node coder has to copy pasta so much stock plumbing for the 1000th time to spin up a small service for a small org?
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.
`create-react-app` is also pretty good, but this seems to do a bit more. I really like the simplicity of the set up and the fact that you can also just whip up an API call or something.
It's an instant tutorial on how this damn mad hatter of an ecosystem works. They heavily commented the thing too !
Honestly, any lecture on react should have a part where people ejects and read the source code.
the page and code styling misleaded me
Now imagine you want parts of your app to be SPA and some other parts of your app to be SSR. This becomes super complex. Frameworks like Reframe allow you to do that. (I'm Reframe's author (https://github.com/reframejs/reframe).)
Admittedly, mixing SPA and SSR views in one app is uncommon today but that's because people are not aware that they can do that. This will change.
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.
This is super interesting, what are you plans regarding this? Super curious.
I still have to have a giggle at the similarities between what you produced and what is essentially a PHP/Dom/Apache setup.
The Async wait for initial props before what is essentially a template render just drove it home.
One key thing missing is an easy wrap around running tests. What would it take to add this?
Lastly, it’s a shame that the doc link points to github. The doc, as layed out in github is a perfect use case for zero.
Every php framework got away from that for really good mesure, including not having your logic in the server document root.
Every php framework got away from that for really good mesure, including not having your logic in the server document root.
Security nightmare? Can I do myapp.com/.env and read the credentials from the wider internet?
Couldn't see it on the main docs site (https://zeroserver.io/)