Replica set with authentication

[Ivan Stoyanov]

I'm on MongoDB 2.0.0 and node-mongodb-native 1.0.2. I have a replica set with authentication. It works fine, then I kill the primary and on subsequent calls I get "Error: unauthorized db:xxx lock type:-1 client:127.0.0.1". It seems like the connection to the new primary is not authenticated.

The connect string is of the form "mongodb://username:password@localhost:30000,localhost:30001,localhost:30002/admin?replicaSet=myset&autoReconnect=true"

I tried the exact same setup with pymongo and there are no problems. I will continue debugging, but I wanted to see if other people have seen this issue and have RS+auth setups.

Is the authentication supposed to happen at the initial connect or when the new primary is discovered?

Thanks,
Ivan

[Ivan Stoyanov]

I think I see the problem but I'm not sure where to fix it as it is a little deep.

Forgot to mention that I not only have auth, but multiple databases in my Mongo instance. I authenticate with a username and password that are in the admin db. Then in the client code I do a bunch of db.db("some_non_admin_db"), which is all fine.

The problem is that when the primary fails and the retry happens:

1) self.auths is not being copied over during db.db, so the unfortunate Db object doesn't even know it needs to authenticate  (but that's a trivial fix)
2) even with the above fix, the Db is no longer admin, but something else, so it can't authenticate with the admin credentials (and that's just an annoying mongo weirdness, but what can you do).

So it feels like the Db and the Connection abstractions are not decoupled enough IMHO to address the mongo admin users weirdness. Under the _retry, we'll have to stop the operation, somehow authenticate the Db the credentials are for, and and resume the operation.

Would love to hear suggestion on workarounds in client code (besides drop the auth).

Ivan

[JimJ]

Ivan,

I too ran into this issue.  To solve this my connect string looks like:

mongodb://username:password@localhost:3000/dbname,mongodb://username:password@localhost:3001/dbname,mongodb://username:password@localhost:3002/dbname

Clunky IMHO, but works.

Jim

[christkv]

Should be fixed in 1.1.2 I would appreciate testing in case I missed any corner cases not covered by integration tests :) it's not marked stable yet as it will go stable with the 2.2 release of MongoDB but any testing appreciated :)

Cheers

Christian