[SERVER-258] Read-only user Created: 25/Aug/09 Updated: 12/Jul/16 Resolved: 02/Feb/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Admin |
| Affects Version/s: | None |
| Fix Version/s: | 1.3.2 |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Mathias Stearn | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 4 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
It would be nice if the auth system supported both full-access users and read-only accounts. Even better if you can support requiring auth only for modification and not for queries, eval, group, etc. There would need to be some way to prevent modification even in server-side JS code. I'm working on an internal web front-end to query the db and it would be great if users could safely write their own group-by queries when the provided aggregators prove insufficient. If I allow that now there is a risk that they could destroy data. |
| Comments |
| Comment by michael haraburda [ 15/Mar/12 ] |
|
I agree with Mr. Waldvogel. I believe this is a useful option, and I interpreted the option the same as he did (i.e. only write operations require authentication, not that some users can only write..) Will this be reconsidered/should a new ticket be opened? |
| Comment by Benedikt Waldvogel [ 24/Feb/12 ] |
|
I understood --authWriteOnly differently. In the wiki I found the following sentence: Which makes totally sense to me and is actually the exact use case that I have: |
| Comment by Eliot Horowitz (Inactive) [ 24/Feb/12 ] |
|
Write only users don't make much sense in the general case as you can't see what you write, and trying to keep number of options smaller. |
| Comment by Benedikt Waldvogel [ 24/Feb/12 ] |
|
What is the reason that --authWriteOnly was removed? |
| Comment by auto [ 08/Feb/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 02/Feb/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 02/Feb/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 02/Feb/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 02/Feb/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 02/Feb/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by Aaron Staple [ 28/Jan/10 ] |
|
Oops, should have read the bug more carefully. This doesn't work for db.eval or group() yet. |
| Comment by Aaron Staple [ 26/Jan/10 ] |
|
You can now give a user read only access by setting the readOnly field in the user config object to true. So, for example: { "user": "foo", "pass": "...", "readOnly": true }There's also a new --authWriteOnly option where only writes have security checking. |
| Comment by auto [ 26/Jan/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 26/Jan/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 26/Jan/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 26/Jan/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by Mathias Stearn [ 03/Dec/09 ] |
|
Read-Write Lock work should make implementing read-only users pretty easy |