dbcli
Startup time causes password entry to display in terminal
I'm not sure if this warrants a bug report, maybe this is a feature request? And it might not be a trivial problem, or related to Python (in that case likely unsolvable) but I'm using this as a replacement for the mysql terminal application.
I immediately start entering the database password into the command line after hitting enter. With the Mysql application the startup time is such that (at least on my terminal) it's impossible to accidentally type a few characters of the password into the terminal window, but with mycli the startup takes a half second longer or so to being capturing keyboard entry, and so I consistently enter the first few characters of the DB password as plaintext into the terminal window. If I mash the keyboard I can consistently enter 12 characters before the password capture starts, in regular use it's more like 3.
I can take a look at the code later, but if off the top of a devs head this is unsolvable just close this issue.
@AlecHansen I think there are ways to speed it up. For instance, I believe the official mysql client only asks you for a password if you use the -p flag (without a value). Mycli has the -p flag, but it's only used to enter a password in plaintext.
Without the -p flag, mycli attempts to login without a password -- if that fails, then the user is asked for a password. I imagine that's the reason for the delay. I could see an argument to replicate the mysql behavior of prompting the user immediately if the -p flag is used without a value.
On a related note, I'm not sure if you're aware that mycli supports mysql's encrypted login path file. That way you aren't prompted for your password and it's not stored in plaintext.
Anyone else have any thoughts?
I could see an argument to replicate the mysql behavior of prompting the user immediately if the -p flag is used without a value.
That's a good suggestion. I'm not sure why we didn't emulate that behavior from mysql. I'll be happy to merge a PR that implements this suggestion. :)
I don't think 'click' options can have variable nargs, though there was a PR for that project to implement that which has not been accepted. So I made a small PR that adds a parameter to force entering the password via the prompt --password-prompt. Is that a good middle ground?
@johnksterling I didn't see your comment here. It's unfortunate that click can't accept empty values for an option.
I just started reading click's docs and I noticed that the prompt option is what we want.
http://click.pocoo.org/5/options/#prompting
What do you think?
Yes - I had originally used password prompting, that is what I was alluding to above. Unfortunately the feature is implemented such that prompt=True ALWAYS prompts if you do not provide the flag. We want it to prompt only if you provide the flag without an arg. I could not find a way with this library to do that which is why I fell back on a new flag. Best path forward might be for us to submit a PR to options to have an optional flag that prompts if there are no args.
Sorry I haven't replied in a while. I'm trying to make a decision about the various password options. There's already two and we're thinking abut adding a third one. I'm not sure how I feel about that. It adds to ambiguity. I'll keep thinking abut this and propose something soon.
On Feb 15, 2017 1:57 AM, "John Sterling" [email protected] wrote:
Yes - I had originally used password prompting, that is what I was alluding to above. Unfortunately the feature is implemented such that prompt=True ALWAYS prompts if you do not provide the flag. We want it to prompt only if you provide the flag without an arg. I could not find a way with this library to do that which is why I fell back on a new flag. Best path forward might be for us to submit a PR to options to have an optional flag that prompts if there are no args.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dbcli/mycli/issues/341#issuecomment-279966754, or mute the thread https://github.com/notifications/unsubscribe-auth/AADAbJE83_08FF1ljL6trBX0eim-fGseks5rcswPgaJpZM4L7DSF .
Sounds good - I also posted a note to the click project to get input. I think the best path forward would be to patch click to allow a hybrid 'prompt' like this: https://github.com/pallets/click/issues/736 I looked at the code and don't think it would be a huge patch to add that to click then take advantage of it with the existing --password option.
Thank you for filing a ticket with click. Let's wait for them to reply and then we'll make a decision about this ticket. :)
On Sat, Feb 18, 2017 at 6:52 AM, John Sterling [email protected] wrote:
Sounds good - I also posted a note to the click project to get input. I think the best path forward would be to patch click to allow a hybrid 'prompt' like this: pallets/click#736 https://github.com/pallets/click/issues/736 I looked at the code and don't think it would be a huge patch to add that to click then take advantage of it with the existing --password option.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dbcli/mycli/issues/341#issuecomment-280850321, or mute the thread https://github.com/notifications/unsubscribe-auth/AADAbCJwT5Fti03v1XCBLS_cRkw_MXhOks5rdwWZgaJpZM4L7DSF .
@johnksterling I noticed that you closed the PR. Was there any movement on the issue?
No, but it appeared that my workaround was not desirable so I figured I'd clean it up until we have direction.
No response on my question to click, so I may just put a PR out to them to force the issue. Without changes on their end we either hold on this issue or do a funky workaround like my previous PR.
John
On Wed, Mar 1, 2017 at 9:00 AM, Amjith Ramanujam [email protected] wrote:
@johnksterling https://github.com/johnksterling I noticed that you closed the PR. Was there any movement on the issue?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dbcli/mycli/issues/341#issuecomment-283346964, or mute the thread https://github.com/notifications/unsubscribe-auth/AEbw7I9Ug--3ZT22JZYIlhYqEiKMEspjks5rhXnrgaJpZM4L7DSF .
Thanks guys, I took @tsroten advice and am using an encrypted password file. I didn't mean for this to become "do tech support for some guy", but I do appreciate him letting me know about that option.
Just to clarify, the official mysql cli will accept a password if it's entered immediately following the flag (without a space). Example:
-
-p<PasswordHere>
With no value after the flag, or if a space is added between the flag and value, you will be prompted for your password. Examples:
-
-p <PasswordHere> -
-p
