WRONGPASS isn't handled correctly

[nerdrew]

When AUTH gets a WRONGPASS back, it leaves the connection connected and all subsequent commands will get a NOAUTH error (assuming the default user is disabled). The client should probably keep track of if AUTH was requested, and then retry AUTH before any other commands are allowed. Would a PR for this be accepted?

[byroot]

Would a PR for this be accepted?

Yes.

But not need to keep track of the comnand sent. Just notice the WRONGPASS error, and close when it happens.

[nerdrew]

Thanks for the quick response :) We had an issue a couple years ago with Elasticache that felt like it was caused by the expense of TLS setup for new connections. Should we worry about the extra TLS expense of closing connections for failed AUTHs (as opposed to just re-AUTH-ing)?

[byroot]

I mean, you can try a patch that doesn't close and instead keep a flag to know if auth worked, if it's not too invasive I'll consider it.

[nerdrew]

Related: a username provided without a password is a no-op. Should it be an argument error to provide a username without a password?

[byroot]

I don't think so. But yeah it's debatable.

[nerdrew]

Here's a PR that closes the connection when WRONGPASS is returned: #275

Here's a PR that tracks prelude "success status" and retries until it succeeds: #276

[nerdrew]

One thing to note: I tried to address any command failure in the prelude, b/c they all look important.