4 ms·
The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Met
by imslavko 12y ago
The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Meteor this is called "latency compensation" and you can read more about it here: https://www.meteor.com/full-stack-db-drivers https://www.meteor.com/full-stack-db-drivers.
Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the actions validation rules still apply on this executed logic and if clients disagree with the server (the privileged environment), clients cannot harm the server state.
- aliakhtar 12y agoQuerying 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?