Hacker News Reader

Comment by aliakhtar | Hacker News Reader

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.

View 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

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.

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?

Reply on news.ycombinator.com