db.createUser() screws up if I don't use quotes
Cannot Reproduce
MongoDB 4.0.10 (Windows x64)
NoSQLBooster 5.1.8
if I execute the following:
db.createUser({ user: "root", pwd: "password", roles: [ { role: "root", db: "admin" } ] });It says success, but I can't actually authenticate with those credentials.
Looking up the user in the system.users collection I see:
{ "_id" : "admin;.root", "userId" : UUID("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"), "user" : "root", "db" : "admin;", "credentials" : { "SCRAM-SHA-1" : { ... }, "SCRAM-SHA-256" : { ... } }, "customData" : { }, "roles" : [ { "role" : "root", "db" : "admin" } ] }
Notice the `db` is "admin;" with a semi-colon at the end... as is the prefix in the `_id`.
However, if I execute:
(note the quotes around the role property names - "role"/"db")
db.createUser({ user: "root", pwd: "password", roles: [ { "role": "root", "db": "admin" } ] });
It works and I can authenticate.
This creates a user record like this:
{ "_id" : "admin.root", "userId" : UUID("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"), "user" : "root", "db" : "admin", "credentials" : { "SCRAM-SHA-1" : { ... }, "SCRAM-SHA-256" : { ... } }, "customData" : { }, "roles" : [ { "role" : "root", "db" : "admin" } ] }
It took me quite a while to figure out why my new DB initialization was failing.
I've never seen this before on MongoDB < 3.6, and I've only just started using NoSQLBooster after migrating from another product.
Any idea if this is a MongoDB issue, or a NoSQLBooster IDE issue?
Thanks.
I follow your steps and run "createUser" script with NoSQLBooster 5.1.8 and MongoDB 4.0.10, but can't recall this issue. It created a user record like this:
I follow your steps and run "createUser" script with NoSQLBooster 5.1.8 and MongoDB 4.0.10, but can't recall this issue. It created a user record like this:
Well, at least I know it's just me and I can work around it.
The same script that fails in v4.0.10 has worked on all previous setups... until today.
If I can't determine what caused it, or reproduce it via the command line/shell it's probably just an anomaly.
Thanks.
Well, at least I know it's just me and I can work around it.
The same script that fails in v4.0.10 has worked on all previous setups... until today.
If I can't determine what caused it, or reproduce it via the command line/shell it's probably just an anomaly.
Thanks.
Replies have been locked on this page!