Improve support for connections without auth (Final PR for 1.14.0) #629
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before we had validation that the user/password was non-empty. This doesn't really make sense for users that have turned off authentication (setting dbms.security.auth_enabled to false in the conf). They then had to input some gibberish password just to get past validation (if they figured this out) and would then be able to proceed whatever the password was (as long as it wasn't empty)
Since we anyway get a reasonable message when a user tries and fails to connect with incorrect password/user (including empty) when auth is activated on the db, I think this check is not needed.
One thing though is that the user is included in the connection-name of the connection like:
<Display name> [<**user**>@<scheme><host>:<port>]But since we can pass any user/password when auth is off, we will always succesfully connect (if scheme/host/port is correct) and can then pass any username and it will be displayed in the connection-name. I suppose we could do a comparison to
SHOW CURRENT USERand remove the "gibberish-username" once the connection is established, but I think it's quite a messy solution for such a small issue (that the user shouldnt cause if they know what they are doing). So maybe we let it be?Actually, thinking more of it, I think the way it is makes sense. We are indeed trying to use this user to connect, so if the server turns on auth this is the user that would validated against
Fixes #596
Closes LS-92