Comment by erikpukinskis | Hacker News Reader

Comment by erikpukinskis | Hacker News Reader

I'm surprised no one is talking about the glaring hole, which is security. It's apparently on the developers' short list of high priority features (http://stackoverflow.com/questions/10100813/data-validation-...) but it doesn't seem like a trivial addition.

With client-side DB access, and eventual consistency baked into the platform as a core feature, you can't just throw "if current_user == object.owner" in your controller and call it a day. I'd love to know what they're thinking here.

Certainly you could go with a row-level security scheme like CouchDB has, where you attach little javascript snippets to your database that check security. But then how does the client verify? Maybe you can just assume that only malicious users will ever bump into security problems and so client-side verification is unnecessary.

If auth is baked into the framework, then maybe they can give you basic row-level security for free by maintaining a user table with auth tokens that's only accessible on the server side, and passing the auth token along with every database request, and maintaining a meteor-controlled owner key on objects. But that doesn't help if your security checks are more involved. I.e.: "if object.owner.friends.includes?(current_user)".

I'd love to hear what they're planning for this.

Posted on SO:

Meteor has data validation already, though not user authentication.

The model is that the server chooses what data to expose for reading, and the server also performs the real writes against the database. The client only simulates the mutations. You can define your own mutations ("methods"), and have them simulated on the client or not. If access checks pass on the client, they still might fail on the server. The server can run additional or different code, and you can hide this code from the client by putting it in the "server" directory. If the method results in different side-effects on the server than on the client, the differences are synced down to the client -- exactly what you'd want.

However, in new projects, to make things easier for first-time Meteor developers, we auto-publish all server data. To turn this off, type "meteor remove autopublish". That is, auto-publishing is the default for new projects but not the default for meteor overall.

That's a common problem with a lot of web frameworks. Every single one of them claims to make "web development" easier. They promote themselves by showing how well they solve some narrowly-defined and often imaginary problem (in this case - client-side updates), but completely side-step all the typical issues that really make web development difficult: user and group management, caching, validation, authentication, permission handling, stuff that prevents XSS, CSRF and injection attacks, version upgrades, dependency management and so on.

Anything can be made to look easy if you're ignoring real-life issues. Heck, you can do seamless client updates by refreshing all the pages on my website every second. It will be inefficient, but it is easily doable.

I think you take for granted some features commonly provided by modern web frameworks addressing what used to make web development difficult. For example, in the pre-Rails era, building just a simple CRUD website used to be difficult.

For arguments sake, if we say there are 20 "real-life issues" then all web frameworks tend to address up to 12. New frameworks are created to address some of the issues of the past frameworks but with regressions in other areas.

Recently, I've been using Lift which happens to be very strong on most of the points you named, yet in retrospect, I don't feel it made web development easier overall because it has other deficiencies.

I was shocked when I saw the client-side DB access in the video. It seems like absolute insanity to me.

Even when I knew very little about web development, the principle of not accessing the database on the client side seemed obvious and very important.

But they aren't accessing the database. They are accessing a data structure on the client, and changes are propagated to the server. There are opportunities to reject that change at the server.

This trick is already in use in a lot of places. If you click an upvote on Reddit, it doesn't do a complete round-trip, it just increments the count in place, and then issues a command to the server to do a "real" increment. If, in the meantime, someone disabled your account, then there is a disagreement. But it's obvious that the client's idea loses.

Eventual consistency is in mainstream use on the server, with frameworks like Cassandra et al. This is just a generalization of that to the web client.

All true, but then you're essentially lying to the client. You are saying something happened, when it didn't.

I understand the argument that this type of lying is "ok" for the sake of responsiveness, since 99% of the time the data will be accepted.

That argument isn't valid in my eyes.

When I update the users screen to reflect the data they entered, to me, that's an indication that I accepted the data. If I were to first show the data as accepted, and then show an error message if something went wrong, I am undermining the trust the user is placing in my software.

It's almost like the software is confused and inconsistent? Kind of like a person who says one thing and then says something entirely different within a few seconds?

With every software suite, there is an implicit promise that it won't try to mislead me. I don't use software that lies to me, I don't expect others will use it either.

From the doc: "Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality."

Yeah, I read that too. :) It doesn't really address my questions about how they'll pull that off.

I would assume their client DB stubs invoke server RPCs. A few server hooks for your webapp would solve that.

There's a really good reason why an API should be written (like REST API for example) between the client and the server, and that the client should not be exposed to the internal workings of the database for many reasons.

The API should be carefully programmed and kept abstract from the database, which might be one day changed completely. To keep the user interface agnostic, it should not be aware of how the database works.

Also, this is a recipe for mistakes, since giving the client direct access to the database (even if it is secured) raises questions about the data integrity and data protection. It is much more prone to abuse that way.

I'd love to see a CAPTCHA signup implementation with meteor.

Reply on news.ycombinator.com