[SERVER-7727] Provide at least two extra free format fields to store user information Created: 20/Nov/12  Updated: 25/Jul/14  Resolved: 17/Sep/13

Status: Closed
Project: Core Server
Component/s: Admin, Security
Affects Version/s: 2.2.0
Fix Version/s: 2.5.3

Type: Improvement Priority: Major - P3
Reporter: Simon Harvey Assignee: Spencer Brody (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 6


Issue Links:
Depends
is depended on by DRIVERS-103 Manipulate user objects exclusively v... Closed
Related
related to SERVER-6246 Manipulate user objects exclusively v... Closed
Backwards Compatibility: Fully Compatible
Participants:

 Description   

Currently the db.addUser command only accepts the user name and password as parameters. This makes it difficult to review users at a later date, e.g. when an entitlement review is performed. It's an even bigger problem if the user is a functional user as it cannot be easily tagged to an owning ID and no description can be entered against it.

It should be possible to optionally enter at least two extra parameters to db.addUser to provide more information such as a description of the user, a master ID for it or the owning ID of it.



 Comments   
Comment by Spencer Brody (Inactive) [ 17/Sep/13 ]

The new user management commands support a "customData" field that can be an object with as many fields as you want, and we promise that the server will never inspect that field directly.

Comment by Andy Schwerin [ 28/Nov/12 ]

The 2.3.x designation means we hope to get it into 2.3 (and hence 2.4), but that it is not a required feature for the 2.4 release. Given the low complexity of the change, I'm hopeful that we can get it in in time for 2.4.0.

What I envision is that we would reserve the field name "extra" at the top level of documents in the system.users collections, to contain arbitrary data required by the customer. We would further change the shell's addUser method to accept an object describing the "extra" information. To use it, a caller would call db.addUser as follows:

db.addUser({ user: 'andy', password: 'frim', extra: { location: "New York", manager: "dan" } })

Users authorized to access this collection would then be able to run queries like the following:

> db.system.users.find({user: 'andy'}, { user: 1, extra: 1 })
{ "_id" : ObjectId("50b4de3458b47af9c6359f2c"), "extra" : { "location" : "New York", "manager" : "dan" }, "user" : "andy" }

Does this match your goals? Keep in mind that in 2.4, the only users authorized to read system.users collections are those that are also authorized to write to them. If you wish to store information about users that can be read by users that lack the user administration privilege, you'll need to store that information in a separate collection.

Comment by Andy Schwerin [ 27/Nov/12 ]

In 2.0, 2.2 and 2.4, a workaround is to perform an update operation on the appropriate document in the system.users collection, to add the desired extra fields.

For example:

> db.addUser('andy', 'frim');
> db.system.users.update(
...    { user: 'andy' },
...    { $set: { extra: { location: "New York", manager: "dan" } } })
> db.system.users.find({user: 'andy'}, { user: 1, extra: 1 })
{ "_id" : ObjectId("50b4de3458b47af9c6359f2c"), "extra" : { "location" : "New York", "manager" : "dan" }, "user" : "andy" }

User accounts that have the rights to run addUser() on a database in 2.4 will continue to have the right to query and perform CRUD operations on documents in the system.users collections, which correspond to user information. These documents are usually called "user documents" and sometimes called "privilege documents" in JIRA tickets.

Generated at Thu Feb 08 03:15:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.