Ability to pass basic auth credentials ...

[Analect]

@ThomasSchellenbergNextCentury ... I think you may be more actively involved in developing these elastic-* elements. I was wondering if I could trouble you.
I've been trying to get some of these elements working against a v5.x elasticsearch installation and one that happens to have basic authentication.
I tried feeding a host like you do here, but include a user:password like this:
'{"host": "http://user:[email protected]:9200"}'

I also tried with something like this:
'{"host": {"protocol": "http", "host": "host.domain.com", "auth": "user:password", "port":9200}}'

However, somehow elastic-client is and/or elastic-client-search are stripping back out the auth credentials ... since I see a POST request in developer tools that is missing the "user:password@" part ...
Any idea on what might be going wrong here ... are these elements set-up to handle basic authentication?

Thanks.

[ThomasSchellenbergNextCentury]

Hello @Analect

The elastic-client component should work with normal authorization. We've actually been using authorization in the production version of our digapp-ht project as part of the host string, like {"host": "http://user:password@host:port"} (which is not committed to the public repo for obvious reasons). I've added some new cases to the elastic-client unit tests to ensure that authorization works as intended. Remember that the POST request will put your authorization under "Request Headers" and will base 64 encode your user:password.

I'm assuming that you're trying to use the elastic-client in your own project? If you're still having trouble, could you please post some example code so I could reproduce the issue locally?

Thanks,

Thomas

[Analect]

@ThomasSchellenbergNextCentury
Thomas,
Thanks for your prompt response.

Just as an exercise in trying to see if this works against version 5.x of ES, I modified some parts of the existing digapp-ht to point to my local ES index .. since this is really the only working app I've been able to find that uses these various digelements.

I create a new 'note' type ... and broadly emulate how a 'webpage' is handled in the digapp. I also change the facets to mimic my own fields and reduce the number of facets to simplify things. Here is the modified index.html ... https://gist.github.com/Analect/2f8bfaadf3bcb5e5478e6fd4d5cfa109. I comment out many of the facets I haven't modified.

Here is what I get when I run the app ... the fact that I am getting a hello=elasticsearch suggests I am able to connect after all with those user:password credentials I am feeding in the config file.

However, the various Bad Search Request errors would somehow suggest lack of compatability with the ejsQuery spawned from the app ... and ES v.5.x-alpha4 ... I know elastic.js has certain query types (filtered queries) that have been deprecated and removed in version 5.x ... I just want to isolate if this might be the source of my errors.

Is there some way for me to log to the console what the actual query syntax is being passed to ES?

Thanks again.
Colum

[Analect]

@ThomasSchellenbergNextCentury
Thomas,
I think the AndFilter() in elastic-client-search and elastic-checkbox-list-filter might be the source of my problems in terms of trying to get this to work in an ES 5.x context, given these deprecations.

I would love to be able to future-proof these faceting capabilities offered by the digelements for version 5.x and beyond. Would you have some thoughts around how either a ejs.boolQuery or ejs.boolFilter, (such as used here might be leveraged to make things compatible again?

While elastic.js has been a great resource to have, from here, it seems there's little commitment to maintaining it, with the docs site now gone. According to that thread, some have switched to a fork or to another library altogether. What are your thoughts on this?

Thanks.

[ThomasSchellenbergNextCentury]

@Analect

I agree with your assessment of the situation. Seeing Bad Search Request errors means it's unlikely to be an authorization issue. It's logical to assume that the errors are a result of the breaking changes to searches in v5. In addition to the changes to queries that you linked, v5 has also removed top level filters which are used extensively in our elements.

As you mentioned, the elasticjs library does not support elasticsearch v5 and is not being actively maintained. I'm sure in the future we will need to add v5 support to the DIG Elements which will likely involve switching libraries. However, this is very low on our list of current priorities and we will not be working on it in the near-term. DIG Elements is an open-source project, though, and we'd always be happy to merge any useful improvements that you may be willing to contribute.

If you're looking to solve this issue in the near-term, I'd suggest forking the elasticjs project and adding new objects to support features needed in v5 like post_filter, must clauses, and should clauses.

Sorry we couldn't be of more help.

PS: In response to "Is there some way for me to log to the console what the actual query syntax is being passed to ES?"
Yes; in fact, yesterday we added a dig-logger component to the digapp-ht project to log search queries to google analytics. You can easily modify this component to log to the console and include additional instances in your index.html page to observe changes on other variables including query objects and errors.

[Analect]

@ThomasSchellenbergNextCentury
Thanks for the detailed response.