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

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

zeroserver.io

Post reply on HN
Print view View original

81–90 of 256 posts

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

#81

Post by wesleytodd »

reidjs wrote: post #58
beefhash wrote: post #57

Earlier quoted context omitted.

> If security is a concern At the risk of being presumptuous... When is security ever not a concern?

Student projects

Pretty sure student projects should teach you something other than `$ npm install`, no?

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?

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

#82

Post by asadlionpk »

q3k wrote: post #75
q3k wrote: 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 [...]

Thanks for pointing this out. Fixed this particular bug!

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

#83

Post by rekshaw »

yodon wrote: post #13
rekshaw wrote: post #2

This is exactly what I needed. However with great abstraction comes great responsibility: you are now the gatekeepers of keeping things efficient in the backend. If I write "require('moment')", will you blindly require, or will you require, tree-shake, minify, etc? I guess my question is: can I trust Zero to always strive for optimum efficiency, or is it just convenience?

If your requirements include "optimum efficiency", you almost certainly are not in the sweet spot for a general purpose zero configuration product.

I guess optimum/optimal efficiency is a lot to ask for, of anyone, let alone a convention over configuration framework, but you get my point!

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

#84

Post by asadlionpk »

wesleytodd wrote: post #77
progx wrote: post #71

Earlier quoted context omitted.

Yes, writting an express backend is really simple, some plugins, error-handling etc. and you can run it in less than 1 hour. 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 i…

Lol, if the setup on the FE takes hours to fiddle something is wrong with the choice of tooling. I don't use webpack, so I guess I am just spoiled?

The alternative is using parcel. Zero is a server equivalent to Parcel (and uses parcel internally)

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

#85

Post by rekshaw »

asadlionpk wrote: post #14
rekshaw wrote: post #2

This is exactly what I needed. However with great abstraction comes great responsibility: you are now the gatekeepers of keeping things efficient in the backend. If I write "require('moment')", will you blindly require, or will you require, tree-shake, minify, etc? I guess my question is: can I trust Zero to always strive for optimum efficiency, or is it just convenience?

I think that's a valid concern. We can certainly optimize and enable tree-shaking (zero uses Parcel to bundle React and HTML). The idea is to implement common optimizations so users don't have to. But also to provide enough escape hatches so advanced users can 'eject' and fine-tune themselves.

Yes please do, I just have a pet peeve against npm modules requiring mb's of files to only use a couple functions. Knowing that Zero does tree-shaking and general optimizations for me will make me happily use for most of my projects!

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

#86

Post by rekshaw »

asadlionpk wrote: post #53
insulfrable wrote: post #50

Minimalism has a cost. http://npm.broofa.com/?q=zero

Standing on the shoulders of giants :) You will eventually be adding all those packages when you develop a production-grade React / Node app anyway.

This is why we need tree-shaking and build-time optimizations to kill the unnecessary.

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

#87

Post by jecxjo »

Cu3PO42 wrote: post #68
q3k wrote: 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…

I don't disagree that this doesn't seem necessarily secure and the auto dependency resolution is a bad idea for other reasons in my opinion, but I don't see the security aspect of it. 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…

Where is the management of requirements? How do you force LTS versions? Or roll back if a version has a vulnerability? When things are automatic you are unable to stop bad things from happening.

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

#88

Post by SahAssar »

Cu3PO42 wrote: post #68
q3k wrote: 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…

I don't disagree that this doesn't seem necessarily secure and the auto dependency resolution is a bad idea for other reasons in my opinion, but I don't see the security aspect of it. 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…

Well, for one giving the app the kinds of write permissions needed for this to work is not exactly ideal.

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

#90

Post by cytzol »

js2 wrote: post #70
cytzol wrote: post #65

Earlier quoted context omitted.

> When is security ever not a concern? 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.

I agree with GP. Security is always a concern. I too used to think as long as it's behind the firewall, or a local only exploit, it doesn't matter. But it always matters. Small apps become big apps. Small user bases large ones. Someone gets onto your internal network and then your small userbase app for trusted employees becomes a jumping off point, etc. Your sort of thinking is how you end up with Yahoo levels of ac…

I think your comment about scalability is accurate. Small apps become big apps, and small user bases get bigger. I’ve seen it happen — but I’m not going to think about scaling to thousands of users when I just need a small application to share with my team. If I spent five days building it to the utmost standards, instead of spending one day on something that solves a problem immediately, I’d be laughed at. It is the same with security.

> 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?

Post reply on HN