[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:
Related
is related to SERVER-36802 Don't omit db.auth() et al from shell... Closed
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: SERVER-5616 Any shell command containing the string ".auth" is not added to shell history

In the case where items such as `db.author` are used, these would
normally be omitted--which isn't what's needed. Furthermore, items like
`db.auth ()` are also permitted, and should not be displayed. This
replaces the existing `strstr` check with a regular expression using
PCRE.

Signed-off-by: Andy Schwerin <schwerin@10gen.com>
Branch: master
https://github.com/mongodb/mongo/commit/e7f372246bacc255231d9b2c5a8d8483881ecdad

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!

https://github.com/mongodb/mongo/pull/215

Comment by Scott Hernandez (Inactive) [ 23/Apr/12 ]

Brian, this is really another discussion, or at least belongs elsewhere; see SERVER-2770

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:

db.getCollection("auth.credentials").find()

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:
> db.auth.credentials.find()
Sat Apr 21 17:39:52 TypeError: db.auth.credentials has no properties (shell):1
>

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?

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