[SERVER-5616] Any shell command containing the string ".auth" is not added to shell history Created: 16/Apr/12 Updated: 22/Aug/18 Resolved: 02/May/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | 2.1.0 |
| Fix Version/s: | 2.1.2 |
| Type: | Bug | Priority: | Trivial - P5 |
| Reporter: | Daniel Pasette (Inactive) | Assignee: | Andy Schwerin |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
Instead of removing only db.auth() lines from the history, any command containing ".auth" is removed. This is annoying because ".auth" is used fairly often, e.g., db.authors.find() or db.issue.find( {"comment.author": "bill"}) |
| Comments |
| Comment by auto [ 02/May/12 ] | |
|
Author: {u'login': u'amcfague', u'name': u'Andrew McFague', u'email': u'redmumba@gmail.com'}Message: In the case where items such as `db.author` are used, these would Signed-off-by: Andy Schwerin <schwerin@10gen.com> | |
| Comment by Andrew McFague [ 27/Apr/12 ] | |
|
Added PCRE code to be smarter about the check, and requested a pull request. I believe this will handle many of the issues, but let me know if this is not what is intended. Tested this out locally against master, and it worked beautifully! | |
| Comment by Scott Hernandez (Inactive) [ 23/Apr/12 ] | |
|
Brian, this is really another discussion, or at least belongs elsewhere; see | |
| Comment by Brian [ 23/Apr/12 ] | |
|
ah, I see... so I suppose the records were actually created and that explains why there was no error message. It does seem a bit confusing to need to use a different (less well documented) syntax for accessing collections in these cases though. I still think it would be preferable if collections could consistently be accessed with the quicker-to-type db.<collectionname> without other database management functions in that scope. I realize that's a separate issue, but it seems related to the general problem of the shell confusing db.auth with the user's intended reference to a collection with a name containing "auth" | |
| Comment by Scott Hernandez (Inactive) [ 21/Apr/12 ] | |
|
Brian, your first issues is not the same as the one described here. You are describing a problem with the mongo javascript shell and our automartic collection resolving – in that fields/functions on the db object resolve first because collect names do. You can get around your first problem by doing this:
The collection name with "auth" at the front is not invalid. | |
| Comment by Brian [ 21/Apr/12 ] | |
|
I'm also experiencing this issue... and I think there's more to this problem than just adding a character to a single string comparison. I initially tried to create a collection with a namespace "auth," so I could have collection names like db.auth.credentials and db.auth.permissions in my application. I didn't realize this wasn't permitted so got cryptic error messages: Ideally this error message should be more informative. My (scala) application also didn't throw any exceptions on trying to insert to this invalid collection, but I haven't investigated exactly which error handling failed. When I figured out what was going on I changed my namespace to "authentication," with collections like "authentication.credentials," and realized that shell history was missing. The filter should only specifically filter out commands that are mongodb specific auth calls that include mongo specific passwords. Even matching db.auth isn't great as someone could in theory have a collection named "db.db.auth." I'm new to mongodb and I'm not sure if it's possible for users to add some kind of trigger/function to a collection? If so, filtering out ".auth(" could also filter out a user function even if the white space issue is solved. But, generally, "auth" is probably a pretty common name for a collection. I realize this might not be great for backwards compatibility, but shouldn't mongodb's internal auth collection be something a bit less intrusive to an application? Maybe have something like "internals.auth" or "mongo.auth" instead of "db.auth" ? Likewise for addUser. | |
| Comment by Daniel Pasette (Inactive) [ 16/Apr/12 ] | |
|
Wouldn't help in the case of ".auth (" – you would have to find occurrence of ".auth", then verify that next non-whitespace char is a "(" | |
| Comment by Tad Marshall [ 16/Apr/12 ] | |
|
Would it help if we did the filtering when we save the history to .dbshell instead of immediately? Even preventing a user from recalling a mistyped db.auth() command two seconds after they type it is a little unfriendly. Would changing the comparison text from ".auth" to ".auth(" fix this? |