Exploring Users and Login methods with Meteor

An experiment to discover some of the alternative ways we can separate authentication into multiple collections, applications and/or databases.

I am writing this while I try and work out the best method for user login on an internal project of mine with a slightly more complex use-case than a standard Meteor application.

Concept Use-Case

A quick overview of the context involves my clients putting their data into our “portal” application and then allowing their customers be able to login and access said data with their own logins setup from their customer records by the client via an external system.

Now the complex part is that we don’t want all the customers to be in the main users collection as the portal is used by our clients for many other applications other than just this feature so this is where the experimentation began.

The Concepts

I pondered over a few concepts to solve the issue that we was facing and narrowed it down to the following:

Concept 1

Running two Meteor applications with two separate Mongo databases, one containing the client’s data and the other containing a user account collection of customers (updated back and forwards when the customer record or the user record is modified in the main database)

This would be implemented by modifying the connection parameter of the Accounts package to talk to a secondary Mongo and Meteor application where the customer logins are stored in the applications own users collection.

Concept 2

Somehow modifying the name of the table that the Accounts package uses to allow customer accounts to be setup using a separate collection such as users_customers while still using the same Mongo database (this would be my ideal concept if it could be achieved)

Let’s get working…

After a quick look through the Meteor source for the accounts-base package, I was able to track down both the connection and the user collection configuration settings.

https://github.com/meteor/meteor/blob/devel/packages/accounts-base/accounts_common.js#L13-21

Concept 1 — Secondary Connection via DDP

So my first thought was to setup a second Meteor project and create a secondary DDP connection to that project from my primary application and then redefine the Accounts.connection to the secondary DDP connection…

Server2 = DDP.connect(“http://localhost:3002");
Accounts.connection = Server2;

Success….through that DDP connection, it is now possible to use Meteor.loginWithPassword etc. for users in the Server2 users collection.

This however seems like a bit of added complexity and an extra level that I don’t really want in my project as I would need to connect back to Server2 to add/modify a customer login as well as always have the second application running to authenticate with.

So onto my next concept…changing the user collection in the same application…

Concept 2 — Overriding the Accounts collection

Accounts.users = new Mongo.Collection(“users_test”);

I removed the original DDP and Accounts.connection code and replaced it with the above, restarted the project and now to run a test and see what happens….

In the browser console, I created a user called “test” by entering the following:

Accounts.createUser({username: “test”, password: “password”})

So far so good…it returned with no error, now to check in RoboMongo and see if the user was actually created in the original “users” collection or the “users_test” collection…*fingers crossed*

Unfortunately not…okay so time to keep digging…

Concept 2A — Overriding the Mongo users collection

Next experiment, I will try re-defining the Meteor.users instead of Accounts.users variable.

Meteor.users = new Mongo.Collection(“users_test”);

Changing the code to the above and re-running the same create user command on the console…but hang on a sec! It didn’t throw a “User already exists” error…

O…M...G… it has worked!

Okay, so now by simply changing re-declaring the Meteor.users variable to a new collection, it seems we can use a collection name other than just “users”

Some additional checking of automatic authentication seems to be working correctly as well, navigating away from the page and back to it showing the Meteor.userId() set to the correct value.

In Summary

So there we go, after thinking that I was stuck with a single collection called “users” for all user logins within the accounts package in Meteor, it seems it is actually possible not only to declare an alternatively named collection for them, but it is possible to use a completely separate DDP connection and application for user authentication if desired.

Thoughts & Concerns

A few caveats that I can think of straight up, maybe some of the packages on Atmosphere will specifically reference the “users” collection by its collection name as opposed to using the collection reference Meteor.users, as well as this has not been tested with Facebook or other third party login sources but I would assume that for the most part it would work correctly.

So it seems it is possible and I will be implementing it into my project in this format along with accounts-password.

Hope this helps others that have been wondering about this concept, it has certainly been a pleasing discovery for myself!