New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
handle nil returns on gets #234
Conversation
Thanks, |
(I work with @soma.) We've gotten A oneliner should be fine – assuming silently swallowing the error is the right thing to do. Maybe raising some exception would be better still? It would certainly be nicer from our perspective to rescue some explicit connection error than a |
I'm still not clear on your usecase and how you get this error. Or is this just a general bug prevention? Here we read from stdin, so it should not be related to network. |
Hm, looking closer at the error. It comes from some code that does The backtrace is
I'm not super familiar with this part of our code (@soma is, I think) but I think that this only happens intermittently, so presumably some connection error makes auth fail and then it tries to prompt, or something like that – I don't believe it's due to a consistently missing password on our side since the error is only intermittent. But I'd like @soma to confirm that. |
There was a change in 2.9.2 (which should went only to 2.10) that changed behaviour of :password authntication to ask for password with prompt if it was not provided correctly. It should not be an issue for interactive apps but for non interactive you need to set :number_of_password_prompts to 0 to get back what 2.9.1 worked. |
Yeah, not super happy about that change :( Breaks things in a weird ways, hanging threads instead of throwing exceptions for instance. Maybe you should default it to 0 instead and let interactive apps set it manually? Interactive usage will probably notice the error better than non interactive apps that just suddenly hangs and causes other strange behaviours in other parts of the system. On Tuesday 24 March 2015 at 00:01, Miklós Fazekas wrote:
|
There was a plan to revert back I'd assume that non interactive apps would use public key auth rather than password. My understading is the password is really for interactive usecase and if you have special scenario requiring use of password in non interactive env then it's reasonable to expect you to do some extra work. |
We always connect with public key, but the problem that happened to us was that the IP for a server changed but not the DNS so the DNS was pointing to a server that wasn't ours and that server accepted passwords. Now our app hanged on the password prompt, causing hard to debug errors.. We did debug it though and can live with it now, but others may still encounter similar problems.. On Tuesday 24 March 2015 at 21:03, Miklós Fazekas wrote:
|
Can you expand on what you mean by "not provided correctly"? I've a strange issue where I have an app failing to authenticate when falling back to username and password for login. I've tried changing the number_of_password_prompts to 0 but I'm still getting the chomp error. |
@os6sense can you give more details about your usecase? So before 2.9.2 if you provided an incorrect or empty password for password auth it did not prompt the user. After 2.9.2 if it fails password auth with given password it tries to ask for password, up to number_of_password_prompts times. So if number_of_password_prompts you should see pre 2.9.2 behaviour. |
ahhh, that's what I needed to know - thank you.
Fixed. This is probably user (my) error, but I'll describe it in the event anyone else lands here with a search for the 'undefined method chomp' error. I've a simple wrapper around Net:SFTP for uploading. Due to some cruddy configuration on the staging server I had a world readable passphrase protected ssh key for a user with the same username that SFTP was attempting to log in as; hence even though a username and password were supplied, the passphrase was being prompted for. Given there is no user input for the passphrase, it was this that was failing with the chomp error. e.g.
If I recall correctly the default behaviour of ssh is to attempt to use public key authentication first so I'd hazard to call this a bug, but it is another place where the prompt/chomp can cause problems. I'm wondering if this patch had been applied, would net-ssh have silently switched to using the supplied username and password? |
Ok so your stacktrace is net-ssh asking for password for public key auth. And in that case number_of_password_prompts should not have any effect. I'm wondering why gets returned nil in your case? Do you have stdin redirected? With this patch the pubkey mehtod would just fail. Then probably it would try with user/password which would succeed |
The application using this is running under Passenger hence I'm not quite sure what happens with stdin.
That's what I thought. Obviously the problem the patch addresses affects multiple areas and I'm not sure that glossing over the cracks is the best idea given that without the chomp exception there would have been an "invisible" bug that would have probably been far harder to diagnose than this was. It would however be far preferable to receive an exception with a higher specificity than that currently raised. |
…ts that more rigorus checking of the password/keys options is required. I've put a quick fix in place but its less than ideal, especially given I discovered there are no tests for the sftp wrapper
@carlhoerberg I've now release 2.10.0 beta1 it adds a new non_interactive option that is expected to be set by non_interactive applications, to prevent putting up prompts from various places. |
This is a simple non-tested fix for an issue we had with this lib. Kernel#gets can return nil in some cases, and this should be handled in some way. You might know a way to do this tested and more dry, but I did not manage to be able to run the tests.