db.createUser() screws up if I don't use quotes

James Price shared this problem 11 months ago
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.

Comments (2)

photo
1

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:

/* 7 */
{
	"_id" : "admin.root",
	"userId" : UUID("c2b57614-3461-4033-407-65692bfb6e23"),
	"user" : "root",
	"db" : "admin",
	"credentials" : {
		"SCRAM-SHA-1" : {},
		"SCRAM-SHA-256" : {}
	},
	"customData" : {
		
	},
	"roles" : [
		{
			"role" : "root",
			"db" : "admin"
		}
	]
},
/d093f0be5d53eb9048c3ae17259ec290

photo
1

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.