+1, was just about to add this issue

👍

Is there any update on this enhancement? Without this, clustering works for systems where we dont need any authentications.

Any progress?

+1 - been trying to figure this out for awhile now!

+1 @chazsolo - same here!

Because of no response from the author and my deadlines coming close, I had to think of an alternative. Here is what I am doing -

I have two copies of my app. One master, with all the publisher and database operations in it: and other slave, with just the ui. So the slave connects to the master using clustering and also has database URL from the run command, connecting to the same database as master.

When the use logs in, the slaves make database calls and does the authentication directly with the database.

When you want to subscribe to the publish information from the master, send user-id with the subscription request and authenticate in the master before publishing to the slave.

@kaushik1979

How are you handling logging in your users? I've written my problem as a question on StackOverflow and am at a roadblock until we get authentication down, as you were.

Our problem is odd and complex, as users will be able to log in to one app (the user-service) with LDAP credentials, while logging in from the other app is pin-based (which is the part that fails). Any ideas/suggestions? We don't want to settle with having separate user accounts for everyone in each service.

I will post some sample code for the slave app shortly. Thanks.

I'd very much like to read about your solution @kaushik1979 thanks in advance.

Any updates on this?

I don't know each case of each one here, but Kadira team released this package: https://atmospherejs.com/kadira/login-state that maybe help.

@kaushik1979 I use an architecture similar, I have two apps, the "back-end" (only server side) and the "front-end" (only client side) - but can be more apps for front-end - and I need the user login on both, to call the operations (methods), so on front-end I use DDP login, has two way to do that:

Using DDP connection for "accounts" package:

// I'm using this packages
// accounts-base
// accounts-password

// Define the DDP backend
Backend = DDP.connect('http://backend.yourdomain.dev');

// Meteor will use Backend connection
Meteor.connection = Backend;
Accounts.connection = Meteor.connection;

In this case need use Backend.call to meteor methods.

But I use this package: https://atmospherejs.com/gwendall/remote-ddp
that make more easy, the "front-end" will see the "backend" like the "server side", so can use Meteor.method normally.

On both case I can login, but after few seconds the user is logged out, Meteor not persist login informations on local storage like a normal app, so my solution is to use login token - after each login the Meteor generate a "token" that can be used as password to login too, so:

// Listen if the token session has value and login with it:
Meteor.startup(function() {
    var token = Session.get('token');
    if (token) {
        Meteor.loginWithToken(token, function(error) {
            if (error) {
                Session.set('token', null);
            }
        });
    }
});

// Save token after successful login, on session:
Meteor.loginWithPassword('email@email.dev', 'password', function(error) {
    if (error) {
        console.log(error);
    }
    Session.setAuth('token', Accounts._storedLoginToken());                                
}); 

I use this package: https://atmospherejs.com/u2622/persistent-session
for "persistent session", only for logged user, if user is logged out this session value will be "null".

Now I can have the user logged on the "front-end" app and the "back-end" app will see it too, so, works like we want. I hope this can help @chazsolo and others, this is my case and works well, but each one can have a different case.

PS: I use different database for each app, my idea is that only the front-end app will be public, and the back-end accept call only from this app, and is hidden for web.

Does this mean meteor-cluster is no good without some serious work if you're using login in your app?

Gives the new AccountsCommon Package wind in the right direction, or is it not the right tool to solve this problem here?

@dropfen which package ? (link ?)

@Xample sorry for the delay
this is what I mean: http://docs.meteor.com/#/full/advanced_accounts_api

I started working on a solution https://github.com/ozsay/cluster-accounts.

Please, review the current implementation. I hope there aren't security flaws, etc..

@ozsay 👍

Any news on this?