After MongoDB was upgraded to 2.4, the User system, or permission system, has undergone dramatic changes. In the User system before MongoDB2.4, except the User name and password, there is only one ReadOnly attribute. If a user logs on to the admin database, the Readonly attribute in the admin database will be followed by all other
After MongoDB was upgraded to 2.4, the User system, or permission system, has undergone dramatic changes. In the User system before MongoDB2.4, except the User name and password, there is only one ReadOnly attribute. If a user logs on to the admin database, the Readonly attribute in the admin database will be followed by all other
After MongoDB was upgraded to 2.4, the User system, or permission system, has undergone dramatic changes.
In the User system before MongoDB2.4, except the User name and password, there is only one ReadOnly attribute.
If a user logs on to the admin database, the Readonly attribute in the admin database will be used in all other databases.
Such permission management is of course the easiest to manage. If any user that can log on to MongoDB has a record in the User table of the Admin database, the access permissions to all databases on the server are fixed.
Of course, users can define their own permissions in user tables of individual databases. The so-called permission is read-only or non-read-only.
After 2.4, the MongoDB user model has undergone great changes.
Login User (before 2.4)
User Name
Password
Read-only or not
Login User (after 2.4)
User Name
Password
Role
Other database roles (if the User logs in to the User table of the Admin database, the User can specify the access permissions for the specific database)
External verification
The concept of "role" is similar to "whether it is read-only". The content is much richer and different roles can perform different operations. Some can manage users and view User tables, some can only see common data tables.
I have been studying users and permissions recently and have summarized my experiences:
1. The ReadOnly attribute can still be used to take into account previous versions. However, ReadOnly and Role cannot coexist.
2. Password and external authentication cannot coexist. either use a password to authenticate the identity, or use an external verification database to authenticate the identity.
3. Other database roles can only log on to Admin.
Next, let's talk about the C # DRIVER: the C # driver, which has not yet begun to correspond to the huge changes made by login users. By myself, I am developing the Login User class that I have adapted myself.
I don't quite understand why the C # driver doesn't correspond to the change of the login user, and I don't know whether the drivers in other languages do not ....
Here is the newly added user GUI
After a user is added, do not forget to add the -- auth parameter when starting MongoDB. Otherwise, authentication will not be enabled by default. No matter who the user is, it is the full Admin permission.
If you are interested in my GUI tools, all the code above Github
Https://github.com/magicdict/MagicMongoDBTool
The tool started to provide performance monitoring tools. Of course, it was just a small attempt.
In addition, IBM recently announced its cooperation with 10gen (MongoDB Development Company. I don't know how much MongoDB is supported by IBM. But in any case, it is a good news for MongoDB fans.
MongoDB is still a cold database. There are few articles about MongoDB in the garden, or even the introduction is an entry level.
Technology is like gambling. Who knows if Mongo will become another Oracle in the next year. No matter what, invest in it first .....
To directly experience the tool: Net3.5 is required ....