1

I'm trying to publish all users to admins only but ommitting certain data (In this case an API key which is supposed to be "private" to each user, I realize that the admin can most likely check the database but let's ignore the security implications for now).

So the basic idea is that a user can see his own profile completely and no one else. An admin can see his own complete profile and a censored version of all other user's profiles. For this I have the following publish code:

Meteor.publish('currentUser', function() {
  return Meteor.users.find({_id: this.userId}, {fields: {'profile.apiKey': true}});
});

Meteor.publish('allUsers', function() {
  var currentUser = Meteor.users.findOne(this.userId);
  return currentUser && currentUser.profile.admin ?
         Meteor.users.find({}, {sort: ['username', 'asc'], fields: {'profile.apiKey': false}}) : null;
});

The problem is that the apiKey field doesn't get published after logging in. Ie. if I simply login as an admin the admin's apiKey won't be available until the page is reloaded. Removing the restriction from the 'allUsers' publish function solves the issue so it must have something to do with this. Is there any way to force Meteor to reload the subscriptions after a login?

Rick
  • 3,240
  • 2
  • 29
  • 53
  • Did you have a look at [this answer](http://stackoverflow.com/a/14150905/1439597)? (and the one below it?) Not sure, but it may help. – SylvainB Jul 08 '15 at 13:11
  • my suspicion is that the two publications overwrite one another as they go into the same collection. You should try to redesign the two publications such that each role uses exactly one publication, or just use one publication with an if statement (which would be better). Right now, I believe, for admins you are trying to use both publications. – Christian Fritz Jul 08 '15 at 16:02
  • Your second publication has a SQL-like sort, needs to be: `{sort: {username: 1}` – Michel Floyd Jul 09 '15 at 03:53
  • @BraveKenny I'll have a look! – Rick Jul 09 '15 at 07:11
  • @ChristianFritz That's probably it, I'll give that a try. – Rick Jul 09 '15 at 07:12
  • @MichelFloyd How does the sorting affect what fields are published? The sorting as such works, as in they are sorted in the correct order. – Rick Jul 09 '15 at 07:12
  • It doesn't - just had never seen syntax like that work!. FYI @ChristianFritz - when multiple publications publish to the same collection and are subscribed to by the client the collection on the client will contain the *union* of the data. So this pattern is fine, no need to just have one publication per user type. – Michel Floyd Jul 09 '15 at 16:46
  • @MichelFloyd: how is that union computed? at the document level or at the document-field level? The problem here is that there are multiple documents with the same id, coming through two different subscriptions. So the question is, which of these two will make the union? I'm assuming the union operation won't keep both copies (and create a new id for one of them). So the question is whether the union in that case merges the two documents and if so, how. – Christian Fritz Jul 09 '15 at 17:08
  • document-field level. Each document will only appear in the client-side collection once (`_id` will be unique) but the fields available for each document can vary. For more see http://meteorpedia.com/read/Understanding_Meteor_Publish_and_Subscribe – Michel Floyd Jul 09 '15 at 21:15
  • @MichelFloyd I can't seem to find the docs where I read about 'sac' but it seems to work ;) But what you're saying about that publication is that it SHOULD work? – Rick Jul 10 '15 at 12:19
  • Yes. You can have multiple publications on the same collection. You still need to subscribe to each one and make sure you're waiting for the data to come across the wire (ex: with a *waitOn* in iron-router or looking at *.ready()* on the subscription handle). – Michel Floyd Jul 10 '15 at 16:26

0 Answers0