-
Notifications
You must be signed in to change notification settings - Fork 149
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
Pushgateway basic auth with special characters in password #170
Comments
@dkirilenko I don't know the PushGateway very well... |
Hey @dkirilenko, just going through old issues and I thought I'd take a look into this one. I'm struggling to see how your monkey patch affects the handling of special characters in basic auth passwords. The current code gets the username and password as parsed by As far as I can tell, your monkey patch allows setting a username and password separately to the gateway URL, but I'm not clear how this would change the handling of special characters. Could you clarify? |
@dmagliola I decided to have a bit of a play with this, and I managed to find an edge case that I suspect may be what @dkirilenko ran into, or at least close to it. Right now, the only way to pass us basic auth credentials is by supplying them as part of the That syntax doesn't have a way to supply an
However, if do pass the decoded form (i.e. I'm not sure if there are other characters that this affects. Surprisingly, colon seems just fine:
but that doesn't hold true for other characters that you'd typically need to encode in a URL:
I'm not 100% sure which way I want to go with this, but I'm leaning towards discouraging the use of the in-URL basic auth syntax. My reasoning there is that while in theory we could URL decode the password (and possibly the username, I'd need to go read up on what those are allowed to contain), we'd be reliant on users encoding them correctly in the first place, which seems like a huge footgun. We could introduce a separate method (or a parameter in We're making a whole bunch of breaking changes to this class in #234 which will land in version 3.0.0 of the library. If you agree on the approach, this would be a good time to land it. |
Yeah, I agree with this plan. I think it's better to set these creds in either the initializer or a specific method (i'd choose one or the other depending on how common we think it is to set creds) And I agree we should either raise or at the very least log a warning if you pass them in the URL, this is a hard one to debug otherwise if you get bitten by this! |
@dkirilenko Thank you for the report! This has been fixed in #242, which will be part of our 3.0.0 release. |
thanks, guys) |
Looks like we can't to make basic auth with special characters in the password. I've implemented fast monkey-patching
Will be great to see this possibility in a new version of gem, perhaps with better implementation
The text was updated successfully, but these errors were encountered: