Meteor 1.4.2 Accounts DDP logs out when page is refreshed

[brucejo]

@nosizejosh,

I had been meaning to write up an explanation of my architecture for myself at some point. Also, I am a picture person. So I created some diagrams that show the architecture.

What I am trying to do:

1. Create a main admin application that can manage the data in the system. This application has access to all of the data that Server A publishes via Meteor.publish.
2. Create a user level application B that has access to a limited set of data. This application has access to a subset of the data that Server A publishes.

---

2 Server solution

Meteor does not prescribe how to create 2 client apps connecting to one server. Meteor can connect to only 1 app by default. (maybe I am wrong about this, but I could not find anything in the Meteor docs describing how to do this).

A solution is to create 2 apps each with their own server. And a shared MongoDB.

Servers and MongoDB

1. Create a meteor project for Server A. This project will use the default meteor port http://localhost:3000.
2. Do not use the default Mongo DB that Meteor creates. We want to create a Mongo DB that can be shared with multiple servers. For this you will want to set up an environment variable MONGO_URL, it is described here. You will also want to make use of Oplog tailing. TheMeteorChef does a good job of giving you step by step instructions. This is a good bit of work, but it is something you will likely need to eventually understand and will need to do it when you deploy. Good to learn early.
   In my case, I set up a running Mongo instance on my dev machine and set it to run at port 27017 (mongo default).
3. Create another meteor project for Server B. This will also reference and use the shared MongoDB.

Servers and MongoDB Colllections

OK, now you can see that Server A stores all the necessary collections in the shared MongoDB. But Server B only has collections supporting the accounts package (e.g. users colection). What does this mean?

1. Both Server A and Server B have the accounts package installed and they each reference the same MongoDB instance. So each one can read and write to the accounts.
2. To make my DB access simpler, I only use Server B for logging in. I do not use it to make user changes (e.g. add users, reset paswords, add authorization capabilities, etc.)
3. Server B does not access any of the Admin or App collections.

Servers and Client application interface ports.

Client A

Client A uses the default connection to its server, http://localhost:3000. And Server A publishes all of its data on that default connection (Accounts, Admin, App). This is pretty simple and straightforward Meteor.

Client B

Client B has 2 connections.

• Its default connection is http://localhost:4000 to its own server. This connection authenticates the user using the accounts package. That is it. To set the default connection to http://localhost:4000 you need to run meteor with the port flag -p 4000.
• Client B has another connection, http://localhost:3000. This is normally the default connection for a meteor app, but for client B it is a foreign connection. So in my example here, this is the microservice url: MICROSERVICE_URL.
  Client B needs to authenticate against its own server and the microservice server. So it connects to the microservice for all of its APP collections and methods.
• Client B only subscribes to a subset of the publications from Server A and Server A makes sure that all users have the correct authorization to access any of the admin collections for app collections.

Now you have it. 2 servers each server with its own client app and a shared MongoDB.

Single Server solution

My reply here is pointing you to a solution that only requires one server. I was unaware of this solution before responding to your thread.

With the single server solution you have some advantages:

1. No need to create a 2nd meteor server.
2. No need to create a shared Mongo DB.
3. You will need to create a 2nd Meteor project that defines the client and utilizes meteor-build-client.
4. This solution does not serve the client bits, so you will need to host those bits somewhere. (you will need a 2nd server, but it can be simpler than a Meteor server)
5. Client B will not need to authenticate with its server, but it will need to authenticate with Server A (not sure how the meteor-build client package would handle including the accounts package.
6. Because this solution does not depend on Meteor to serve the bits it does not support hot code push.

I think there are drawbacks:

1. No hot code push.
2. Need to support another server technology.
3. To be investigated: using the accounts package with a meteor-build-client constructed client.

Which to choose?

My take, for me it is easier to create 2 Meteor servers because I am not that familiar with other technologies. Plus I like the hot code push technology and I plan to take advantage of it.

I can certainly see for certain applications it would be very useful to be able to create a client only build of a meteor app and host it on another server.