Implementing Secure Reactive Data Flow in Meteor 2.x

The Core Engineering Decision

To maintain security and performance in a Meteor 2.x application, you must separate your data paths: use Publications for reactive reads and Meteor.methods for all writes. This architecture ensures that the database remains private on the server while providing the client with a real-time, synchronized cache called Minimongo.

Avoid the legacy allow/deny pattern, which exposes your database to client-side manipulation. Instead, enforce all business logic and authorization on the server. Note that this guide assumes the Fiber-based runtime of Meteor 2.x; Meteor 3.0 introduces breaking changes by replacing Fibers with async/await.

The Mechanism: Publish/Subscribe and Methods

The Publish/Subscribe pattern creates a reactive link. The server defines a publication that returns a MongoDB cursor. The client subscribes to this publication, and Meteor automatically pushes the initial data set and subsequent incremental updates (diffs) to the client's Minimongo cache. When MongoDB Oplog tailing is enabled, the server watches the database logs for changes, pushing only the modified fields to the client.

Meteor Methods handle mutations. A method is a function defined on the server that can be called from the client. While you can define a "stub" on the client for latency compensation (optimistic UI), the server execution is the only authoritative source of truth.

Worked Configuration Example

Below is a secure implementation for a task management feature. Run the server-side code in a server-only file (e.g., /server/main.js) and the client-side code in your frontend components.

Server-side: Publication and Method

import { Mongo } from 'meteor/mongo';
import { check } from 'meteor/check';

export const Tasks = new Mongo.Collection('tasks');

// Secure Publication: Only send documents owned by the current user
Meteor.publish('tasks.mine', function () {
  if (!this.userId) {
    return this.ready();
  }
  return Tasks.find(
    { owner: this.userId },
    { fields: { text: 1, createdAt: 1, owner: 1, checked: 1 } }
  );
});

// Secure Method: Validate input and enforce ownership
Meteor.methods({
  'tasks.insert'(text) {
    check(text, String); // Validate type
    if (!this.userId) {
      throw new Meteor.Error('not-authorized', 'You must be logged in.');
    }
    return Tasks.insert({
      text,
      createdAt: new Date(),
      owner: this.userId,
      checked: false
    });
  }
});

Client-side: Subscription and Call

import { Meteor } from 'meteor/meteor';
import { Tasks } from '/imports/api/tasks';

// Start the reactive subscription
Meteor.subscribe('tasks.mine');

// Query Minimongo (this is reactive)
const myTasks = Tasks.find({}, { sort: { createdAt: -1 } });

// Execute the write
const addTask = (text) => {
  Meteor.call('tasks.insert', text, (err, res) => {
    if (err) {
      console.error('Insert failed:', err.reason);
    }
  });
};

Limits and Trade-offs

• Memory Overhead: Every active subscription consumes server memory. Publishing large collections without limit or fields filters can lead to O(n) scaling issues, slowing down both the server and the client's browser.
• Method Non-Reactivity: Methods are one-off requests. They do not "push" updates. If you need a value to update in real-time, it must be part of a publication.
• Oplog Dependencies: Real-time diffing requires a MongoDB Replica Set. If the app is running on a standalone MongoDB instance, Meteor falls back to polling, which increases database load and latency.

Common Engineering Mistakes

• Over-Publishing: Returning Tasks.find({}) without a selector leaks the entire database to every connected client. Always scope publications by this.userId.
• Trusting Client Arguments: Passing a userId as an argument to a method is a security flaw. Always use this.userId on the server to determine the authenticated user.
• Security in Stubs: Placing validation logic only in a client-side method stub. Stubs can be bypassed entirely by calling the method via the browser console; all security checks must be duplicated or exist solely on the server.

Practical Verification

To verify this implementation, perform the following checks:

1. Data Leak Test: Open the browser console and run Tasks.find().fetch(). Ensure you only see documents belonging to your user ID, not documents from other users.
2. Validation Test: Call the method with an invalid type (e.g., Meteor.call('tasks.insert', 12345)). The server should return a check error and no document should be created in MongoDB.
3. Reactivity Test: Open two different browser sessions with the same user account. Insert a task in one; the second session should update automatically without a page refresh.