News for hackers. Stuff that matters.
Re:Meteor hits 1.0 by aliakhtar on Tuesday October 28, 2014 @10:09PM (#8525105)
Querying your database from client javascript seems like a bad idea. Even if they're not real queries, you are exposing the internals of your system, db column names / queries, etc.
Re:Meteor hits 1.0 by denom on Tuesday October 28, 2014 @11:37PM (#8525396)
This is something that I've wrestled with when working with meteor, how do you execute privileged queries from the client? You can do a 'Meteor.call' to execute code on the server, but there is no way to shield the user from accessing the parameters used in the query.

Traditionally, you would use a cookie on the client to authenticate and trigger the 'privileged' query during the http request cycle. As far as I can tell there is no way to do this with Meteor. Another way to phrase it is there is no authenticated server-side state modeling the client.

Re:Meteor hits 1.0 by dandv on Wednesday October 29, 2014 @03:29AM (#8525971)
In the same vein, there's no way to shield the user from accessing the parameters of a REST request. Which incidentally is easier to replay outside the browser than a Meteor.call().
Re:Meteor hits 1.0 by denom on Wednesday October 29, 2014 @09:21AM (#8526984)
After doing some poking it looks like you can access `this.userId` in the server-side publish and Meteor.methods functions. That's enough to prevent a lot of client-side tampering
Re:Meteor hits 1.0 by nathan-muir on Wednesday October 29, 2014 @04:44AM (#8526112)
How is this different to consuming a REST API and rendering client side?

You can only view & modify data on the client that has already been published.

Data that you don't publish / is server only, will remain so.

Re:Meteor hits 1.0 by kristiandupont on Wednesday October 29, 2014 @06:33AM (#8526429)
Why would that be a bad idea? Unless you are relying on security through obscurity, which you are hopefully not, that shouldn't create any threats?