-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comma in strong password incompatible with connection string format #680
Comments
Agreed - this needs some kind of escape syntax. Totally valid point. |
I was thinking about how to make this work with existing connection strings. What if in the parser, checked if the contents after a comma following |
I've always had kinda bad luck special-casing things like this. Sometimes it works great; most times [for me] I get caught with a situation where it works out now but then there's one more thing it turns out needs special casing and back-compat means I'm stuck. Curious if you could have something in the parser that allows for, like, metadata in the connection string. Maybe a value indicating the parse version first, like
If the first arg starts with Another idea might be to allow the parser to support quoted CSV style things, so this would work...
and your password could be in quotes...
and if you need a quote in your password, the stuff inside quotes could support escaping
If the value after Of course, maybe passwords with commas are also rare. |
what concerns me is that most scenarios change how existing values could be interpreted; for example - Idea (@NickCraver thoughts?): what about if quoted values are allowed, but only if the key is also quoted? today, quoted keys aren't a thing, so there is no ambiguity; for example
would assign the password
questions:
|
I'd say it's not very intuitive (so my fear is someone hitting the issue ever finding the fix), but: I have no better ideas! Any thoughts on how we could assist a user in finding this? Perhaps as part of a parse error message? |
No directive means parse as it works today. |
@tillig I think I actually prefer that to my other suggestion, although I think if we went that route, we'd define that it must be specified at most once, and as the first option, and as a single character @NickCraver in terms of discoverability: we can generate |
We have an auto-provisioned Redis instance in a cloud environment. The password we're provided is generated for us, is very long, and has a lot of special characters... including, sometimes, commas.
We then have systems that try to attach to Redis using a connection string. Unfortunately, the way SE.Redis parses connection strings based on comma delimiters, it means if our generated password has a comma in it, then part of the password gets interpreted as another host. Exception messages have stuff like this buried in them:
SocketFailure on *9?9pi?aK__6fAKSH:6379/Subscription
(where*9?9pi?aK__6fAKSH
is the half of the password after the comma).Looking through the parsing code it doesn't appear there's a way to escape commas. That might be a good addition to help in edge cases like this.
The text was updated successfully, but these errors were encountered: