-
Notifications
You must be signed in to change notification settings - Fork 53
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
Added support for auth token endpoint #142
Conversation
… for configurability
Authenticate with an auth endpoint
…lines at end of file)
@dingobar I love the changes in this PR. Something that could be added to address the life span of the token is for example
what do you think @dingobar? |
In order:
For now, it would be nice if I could get the current feature set reviewed, perhaps with backwards compatibility for the above ideas in mind. The features implemented in this PR covers our use-case at our company, and I have only limited resources for further commitments unfortunately. What do you think? |
@castorm Any chance we could revive this project somehow? I think it's an awesome connector and it will have many use-cases in our organization. |
What about letting the user set a fixed TTL on the token? In our case I know the token will be valid for one hour so I wouldn't have a problem using that. |
Please see attached diff. It's an initial go at caching the access token for a fixed time. The token is saved for "http.auth.tokenexpirytime" seconds. The default value of 0 continues the current behaviour or fetching a new token on every request. Not sure if it's the proper way of storing the data locally in private properties, but at least it works ;) I also took the liberty ot changing how to find the token from path() to at(), given that our token result looks like this
|
@lobbin Fixed TTL for the token given in the connector config is fine. However, seeing as this project is pretty dead the past months (no master branch commits since june 16th this year), I won't spend any more time on this until I get a reply from one of the maintainers of this repo. We are not wanting to support our fork of this project and just wanted to introduce some new functionality, so if the community is dead that unfortunately means we cannot use this software for now... |
@dingobar Yes, I saw that as well. However, I haven't found any other suitable connector so I'm stuck with this one for a while longer. |
Hi @dingobar and @lobbin, Thank you very much for your contributions. I'm sorry it took me a bit to reply, I wouldn't say this project is dead, but I definitely don't have the time or incentive to spend too much time on it, so I'd be happy to accept new maintainers if you are up for the task. Regarding this particular contribution, I'd love to merge it, as this feature is a recurrent request. However, I'd like for a couple of things to be considered before moving forward, and I perfectly understand if you wouldn't want to invest any minute on it. In any case, those things are:
Again, thank you very much for your contribution, I believe even if the project is not as active as it used to be, it's still used by some people, and I'm sure this feature would be very much welcome. So I'll be happy to hear back from you. Best regards. |
Thanks for the reply - I'll see if I can implement those changes. About your time and the state of this repo, I agree that this is a very nice plug-in to connect and it will have immense value for us if we manage to implement it. Perhaps you could ask some of those people who you know use it and have contributed to it in the past to help you maintain it? I think the most crucial thing is being able to merge bugfixes and security patches and release them to confluent hub. Perhaps a conversation for another issue. |
I understand this plugin has gone a bit stale, but this would definitely be a welcome feature. |
I unfortunately no longer use Kafka Connect. I welcome you to take over the feature and implement the requested changes from @castorm . |
I would like to try this or perhaps complete it if possible. |
@dingobar or @castorm, can you give guidance on how I might help? Above you say you want integration tests as well as adaptation to work with OkHttp's Authenticator. I'm not sure I can get my environment set up to build or run integration tests. Also, for what it's worth, I think fetching a token perhaps should be done preemptively, not having to get a 401 before doing so. If Token_Endpoint is the mode but we have no token, my vote is we should go get one before attempting the API call. |
This adds the
TokenEndpointAuthenticator
class, which can be used to retrieve an auth token by making a POST-request to an HTTP endpoint before each poll. It is not the most efficient approach possible, as these types of tokens have a life span which is typically far larger than the desired polling interval (some providers such as Okta charge per. token too), but at least it is a start and it can be expanded later.These config attributes were added:
Here is an example of a connector which also shows the three new config parameters added:
I have also added a dev-dependency (mockhttpserver) to be able to test this functionality with okhttp calls mocked.
What do you think?