enhancement(http-client): Add automatic bearer token acquisition in http-client #21023
Conversation
| HttpClient::new_with_custom_client(tls_settings, proxy_config, &mut Client::builder(), None) | ||
| } | ||
|
|
||
| pub fn new_asdasd( |
There was a problem hiding this comment.
please don't look at names right now :) I just wanted to make it working end to end :)
|
hi @jszwedko can you please help with reviewing this contribution? |
Hey! Yes, apologies for the delay. I'll try to get this reviewed next week. |
hi @jszwedko, a gentle reminder |
|
Hi all, thanks for this contribution! FYI I see a conflict and a failing CI check. |
| token: Arc<Mutex<Option<ExpirableToken>>> | ||
| } | ||
|
|
||
| impl<B> Clone for OAuth2Extension<B> { |
There was a problem hiding this comment.
I think you can add #[derive(Clone)] to OAuth2Extension and delete this manual implementation.
There was a problem hiding this comment.
👋 Hi @KowalczykBartek, I took a look at both PRs. Can you share a config example for this method? Then we can compare it with this config.
I also think enhancing the http client is preferable since other sinks will benefit from these options. One note here, we want to ensure we are not affecting the existing behavior and that should be easy to do with sensible defaults for the new options.
There was a problem hiding this comment.
@pront both are in this PR, for the first approach its #21008 (comment)
sources:
my_source_id:
scrape_interval_secs: 1
type: http_client
endpoint: http://127.0.0.1:9898/logs
sinks:
my_sink_id:
auth:
strategy: "o_auth2"
client_id: "some_client_id"
client_secret: "client_secret"
token_endpoint: "https://some.url/oauth/token"
type: http
encoding:
codec: raw_message
inputs:
- my_source_id
uri: http://127.0.0.1:9091/outputso, its sink aware configuration, and second one is one you linked,
sources:
my_source_id:
scrape_interval_secs: 1
type: http_client
endpoint: http://127.0.0.1:9898/logs
sinks:
my_sink_id:
http_client_authorization_strategy:
auth:
strategy: "o_auth2"
client_id: "some_client_id"
client_secret: "client_secret"
token_endpoint: "https://some.url/oauth/token"
type: http
encoding:
codec: raw_message
inputs:
- my_source_id
uri: http://127.0.0.1:9091/outputI also think enhancing the http client is preferable since other sinks will benefit from these options
if we can agree on this - I can prepare new PR (without all the mess I introduced - and without the conflict :) ) for this approach
There was a problem hiding this comment.
if we can agree on this - I can prepare new PR (without all the mess I introduced - and without the conflict :) ) for this approach
Thank you @KowalczykBartek, sounds good to me 🚀 Please close the PR you don't intend to work on anymore.
There was a problem hiding this comment.
hi. note that in the original issue #20635 i also described the need for a client certificate for the token request that targets the issuer. this is separate from the client certificate that might be configured for the sink's http target.
This is the same problem solved but with different approach #21008 . (another idea for #20635.)