4 ms·
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
by aliakhtar 12y ago
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.
- denom 12y agoThis 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.
- dandv 12y agoIn 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().
- denom 12y agoAfter 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
- deleted 12y ago[deleted]
- nathan-muir 12y agoHow 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.
- kristiandupont 12y agoWhy 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?