-
Notifications
You must be signed in to change notification settings - Fork 64
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
[FEATURE] Allow basic auth for non-cloud node types #308
Comments
Through code you can always create your own transport (or reuse one from an ElasticsearchClient): loggingBuilder.AddElasticsearch(CreateTransport(), loggerOpts =>
{
//
}, channelOpts =>
{
//
}); static HttpTransport CreateTransport()
{
var pool = new SingleNodePool(new Uri("http://localhost:9200"));
var config = new TransportConfiguration(pool)
.Authentication(new BasicAuthentication("u", "p"));
return new DefaultHttpTransport(config);
} Through config however
I will create a PR to rectify this, thank you for bringing this to our attention @irontoby! |
@Mpdreamz thanks for the update, I saw the option to add my own HttpTransport but once I started looking through the code I wasn't comfortable enough in creating my own instance and being sure I didn't miss anything. But I'll give your code a try! |
#313 should fix configuring authentication through config. |
ECS integration/library project(s) (e.g. Elastic.CommonSchema.Serilog): Elasticsearch.Extensions.Logging
Is your feature request related to a problem? Please describe.
Our self-hosted Elasticsearch instance requires HTTP basic auth. (Note, we are using the docker-compose setup from this project). However, the
Username
andPassword
config settings are only used for Cloud node types.Describe the solution you'd like
Allow using
Username
/Password
for single node pools also.Describe alternatives you've considered
I was able to work around this by using e.g.
https://username:password@example.com
as the URL but it would be better if I could store the username/password separately and provide them via secure means (Azure KeyVault in our case).Additional context
It looks like fixing this would also involve updating
SingleNodePool
fromelastic-transport-net
to have the sameAuthenticationHeader
asCloudNodePool
so I wasn't sure if I should file an issue in both places. I didn't see any existing related issues in that repo either.The text was updated successfully, but these errors were encountered: