HTTP API does not work with tokens when registering services through the catalog

[jacobat]

I'm running a Consul server with ACL's enabled, defaulting to deny all access, and having a master token of "secret".

I have an agent_service.json file:

{
  "Address": "127.0.0.1",
  "Name": "agent_service"
}

and I can use it to register a service through the HTTP API:

curl -v -XPUT -d @agent_service.json http://192.168.51.2:8500/v1/agent/service/register?token=secret

I also have a catalog_service.json file:

{
  "Node": "node0",
  "Address": "192.168.0.1",
  "Service": {
    "Address": "127.0.0.1",
    "Service": "catalog_service"
  }
}

but when I try to register it through the API:

curl -XPUT -d @catalog_service.json http://192.168.51.2:8500/v1/catalog/register?token=secret

I get "Permission denied".

Logs:

    2015/06/15 14:34:59 [INFO] agent: Synced service 'agent_service'
    2015/06/15 14:35:11 [WARN] consul.catalog: Register of service 'catalog_service' on 'node0' denied due to ACLs
    2015/06/15 14:35:11 [ERR] http: Request /v1/catalog/register?token=<hidden>, error: Permission denied

I'm thinking this may possibly be related to #891.

[ryanuber]

Hi @jacobat, Was this working previously? I don't think we have supported the ?token query parameter on the catalog register/deregister endpoints. Internally we embed the token into the JSON payload when registering/deregistering from the catalog. Since the catalog is mostly used as an internal endpoint by the agent, we never parse the ?token field out of the request. You should be able to pass in the token field for catalog register/deregister like this:

{
  "Node": "node0",
  "Address": "192.168.0.1",
  "Service": {
    "Address": "127.0.0.1",
    "Service": "catalog_service"
  },
  "WriteRequest": {
    "Token": "secret"
  }
}

I can see how the inconsistency with the other methods is a bit confusing. We could maybe support the ?token flag as an "override"-type mechanism.

[ryanuber]

I've updated the documentation to include the current WriteRequest block for register and deregister actions in c8f76b5

[jacobat]

I've only just tried this today and was surprised that the token query param did not work. It would indeed be nice if Consul had a uniform way of passing tokens.

[tgwizard]

May I suggest a header then, such as Authorization: Bearer <token> (if we consider these tokens bearer tokens, which we could)? It is a bit weird to pass query parameters on POST/PUT/requests.

[blalor]

I agree that a header would be ideal. I also ran into this when attempting to register a service via the catalog api.

[xakraz]

+1 for the HTTP Header for the uniform mechanism

[kamaradclimber]

apparently in consul 0.7.0, the header X-Consul-Token works but WriteRequest method does not work anymore (it used to work in 0.6.3)

[AntonOfTheWoods]

Ok, I'm really confused - apparently ...?token=mytoken does work in 0.7.0 and as @kamaradclimber points out, WriteRequest no longer does...

[slackpad]

Sorry for the confusion - this was fixed in #1893 which ended up overwriting what was specified in WriteRequest. Now the catalog endpoints support the regular ?token= and X-Consul-Token request header like other endpoints. WriteRequest is no longer supported, so that has been removed from the docs.