-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: restrict which cursors are published #42
Comments
Is there currently a way to restrict certain fields from being returned from a top-level "find" even if you don't need them to run the child query? Queries such as the following don't seem to work in any context, which makes security management more difficult: |
Yes there is. Meteor syntax is |
Looks like I need to reread the docs. Thank you. |
This may be somewhat related to the discussion in #28. |
It relies on the private function |
True - it would be possible to instead simply duplicate that function here, it's fairly simple.
I don't understand this, if anything removing the call to |
My mistake. I missed that you moved that functionality into the other observe handler. In poking around, it looks like the Meteor folks are moving the diff logic into a separate package called diff-sequence. I was unable to add this package to a new meteor project. Perhaps it's still under development. Probably worth waiting until they've sorted that out, or, as you said, copy this new implementation until they do. I do think this is a good idea. I'm leaning towards a |
any news with |
At the moment, everything returned by a top-level "find" is automatically published to the client, but I only want the children to be published.
Similarly, sometimes you only want certain fields to be published, but you need all the fields to run the child query. For example, I have a field
user.secret
which I use as part of a child query, but I don't want to publish that field to the client.The first feature can be implemented by an option "internal: true" or similar, the second by adding a field specifier to the options, eg. "fields: { secret: false }"
The text was updated successfully, but these errors were encountered: