-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
feat(inputs.influxdb_listener): Add token based authentication #13610
feat(inputs.influxdb_listener): Add token based authentication #13610
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@srebhan thanks for this PR and looking at this feature request.
Looking at the original request, the user seems to be asking for "token" authentication. When I think about token authentication, especially in reference to v2, I think of the generated string API tokens, not a JWT token.
Effectively I was thinking we would have a a token
value just like we have in the influxdb_v2 output.
Was that not your understanding?
Thanks!
@powersj I talked to Geoffrey yesterday and he pointed me to the 1.8 server code. I reproduced what is there. The downside of a fixed token is that it cannot have an expiry date and token without an expiry won't work with InfluxDB 1.8... |
That is not my understanding of reading the feature request. The background is a user is transitioning from v1 to v2 and wants that process to go more smoothly. The current behavior lists:
They want the v1 input plugin to support tokens which is a v2 auth mechanism. Looking further down they use the go client library as an example:
The JWT tokens are a legacy 1.8 auth mechanism, which is why I still think the correct item is allowing a username/password via a token value? |
Sorry, but isn't this what I added in line 116? What am I missing here? I just added all documented auth mechanisms as per documentation, so you can use |
If I was a user who wanted to use backwards compatibility, again I was expecting a token parameter in the sample config itself, again similar to the client libraries. You are re-purposing the basic auth username and password configuration fields. To someone coming from v2 that is not obvious that they can use that as a token backwards comparability. At the very least you need to update the docs. |
I've gone through this again and realized my comment may have come across a little harsh - my point is that the code is fine, rather we have not guided the user to the fact that this is even possibility. Updating the sample config section near basic auth username/password to state that these can be set for users using compatibility mode via "username:password" is all that is needed to land this. |
@powersj no worries about the comment, I don't classify this as harsh, you have to try harder! ;-) Will add a comment as soon as possible to the sample-config. |
Download PR build artifacts for linux_amd64.tar.gz, darwin_amd64.tar.gz, and windows_amd64.zip. 📦 Click here to get additional PR build artifactsArtifact URLs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
resolves #9445
This PR adds token based authentication to the InfluxDB v1 listener to complement the authentication methods supported. This is especially relevant to get a forward compatibility with v2.x.