Future consul version will no longer support deprecated token authentication through query parameter.

[yapkm01]

According to the excerpt from HashiCorp site:

Deprecating authentication via token query parameter Providing a Consul ACL token in API requests using the token query parameter is deprecated and will be removed in a future Consul version. Instead, you should provide the token through the X-Consul-Token header or with the Bearer scheme in the authorization header as described in the API authentication documentation.

Future consul version will only support token authentication through header X-Consul-Token or Bearer scheme. Is there any plan for Spring Cloud Consul to provide support for this new feature especially using the X-Consul-Token header and when will it be available? Thanks.

[TwinkleTShah]

Hi All/ @spencergibb , Is there any tentative plan for this token authentication via X-Consul-Token header?

[tbadalov]

There is a PR in com.ecwid.consul:consul-api to fix this: https://github.com/Ecwid/consul-api/pull/245

However, the project seems to be abandoned.

Edit: An ugly fix could be setting a custom HttpClient when building a ConsulClient with an interceptor that manually adds x-consul-token when there is such a query param

[oliverlockwood]

There is a PR in com.ecwid.consul:consul-api to fix this: Ecwid/consul-api#245

However, the project seems to be abandoned.

Edit: An ugly fix could be setting a custom HttpClient when building a ConsulClient with an interceptor that manually adds x-consul-token when there is such a query param

I had a brief look into this; clearly such an interceptor could add such a header relatively easily (albeit ugly, as you point out) - however, rewriting the URL to remove the query parameter looks like it would be a significantly more complex undertaking.

An alternative, simpler approach may be to migrate to using this fork of consul-api: https://github.com/jon5477/consul-api, which appears to have addressed this issue and to be actively maintained, while retaining the class co-ordinates that Spring-Cloud (and any other consuming code) references. I will investigate the feasibility of this (adding the dependency, and excluding any transitive dependencies on the abandoned project, with Maven enforcer rules to make sure), and then I will report back.

[spencergibb]

In 5.x we no longer use a third party API, so we have total control. Older versions will not change to a different third party jar.

[oliverlockwood]

In 5.x we no longer use a third party API, so we have total control. Older versions will not change to a different third party jar.

Good to know, thanks Spencer.

For those who aren't yet able to move to Spring 5.x, I can report back that the solution I proposed in my previous comment seems to do the trick.

[oliverlockwood]

Further to my previous message: we subsequently found that there were some aspects of the jon5477 fork which weren't up to scratch for our use-case - some of the operations still pass a Consul token in a token query parameter instead of an X-Consul-Token header.

We've created https://github.com/dalet-oss/consul-api/ which is forked from the original library, with one of jon5477's changes cherry-picked, and our own implementation of ensuring tokens are always sent as headers. It's published to Maven Central. Hope it's useful to somebody reading this message.