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.
[ Parent
| on HN ]
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.
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().
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?