Comment by MichaelGG | Hacker News Reader

Comment by MichaelGG | Hacker News Reader

Parent Full thread

ASP.NET enabled a lot of certain types of developers to quickly drag-n-drop web apps just like they did with VB Windows GUIs. The amount of code needed was pretty cool. Sure, it resulted in a less-than-ideal webpage, but it worked. VB.NET wasn't really a foundation; it had major changes from VB6 and had feature parity with C# (and more in some cases). Javascript is by far a much worse language. What should we expect from a 10-day design?

If this guys is going off about how it shaves a week or so off a 5 week project, problems that appear on bigger apps might not be high on his priority list.

I wonder if Meteor will end up introducing security holes like ASP.NET, as developers forget there's an abstraction and clients can't be trusted? (In ASP.NET, things like being able to screw with viewstate or fire events for disabled controls.)

I still have the hope for a unified platform. But I'd much prefer it to be on a solid language that compiles down to JS. I'm not sure it's an unattainable goal. I think you nailed it with "seamless" and "invisible" - abstracting major things like client versus server, or local versus network, can really end up biting developers.

>I wonder if Meteor will end up introducing security holes like ASP.NET, as developers forget there's an abstraction and clients can't be trusted? (In ASP.NET, things like being able to screw with viewstate or fire events for disabled controls.)

This is a thing for Meteor already. For example, if you have the insecure package enabled, you can can make changes directly to the database from the browser console. However, this particular issue can easily be detected prior to deploying to production.

Insecure is there to help speed development when you are getting started.

All frameworks can do their best to compensate for security holes, but ultimately people need to pay attention to it. That being said, Meteor offers a call method and code runs on the server - if security is a concern then you should pay attention to what happens on the server.

I've not used Meteor. How exactly does "insecure" help speed development? Certainly any code you write with it is worthless, right? I mean, before production you need to remove it and rewrite it using another method, so what's the point? Or do you mean it's useful on the sysadmin side, as a REPL-like data access console?

From meteor.com:

>By default, a new Meteor app includes the autopublish and insecure packages, which together mimic the effect of each client having full read/write access to the server's database. These are useful prototyping tools, but typically not appropriate for production applications. When you're ready, just remove the packages.

It makes it easy to run DB calls from the chrome console to insert and modify test data

While you are right, my view is simply that any developer incapable of understanding the difference between client and server has a snowball's chance in hell of actually creating something secure. Meteor may abstract some of the drudgery of client-server communication, but you still have to know the difference - both for security and implementation.

Reply on news.ycombinator.com