Grafana: Expired Grafana keys still exist in the ether (or maybe the database)

Created on 23 Sep 2019  ·  3Comments  ·  Source: grafana/grafana

I am confused to the process that Grafana is using for expired tokens. From the Grafana API documentation, the field secondsToLive in the API key creation rest request allows you to set an expiration for new keys.

curl 
  -X POST 
  -H "Content-Type: application/json" 
  -d '{
    "name":"testKey",
    "role":"Admin",
    "secondsToLive":60
  }' 
  http://removed:forsecurity@localhost:3000/api/auth/keys

This example shows how I am implementing. After one minute, I would expect that the key would be expired, the key removed from the UI, and the key would then be able to be created again.

What I am actually seeing is that the key is expired, the key is removed from the UI, and another key with that name "testKey" can no longer be created.

Is this normal behavior with api key creation? I would think this would be breaking for public facing API. Is it perhaps something specific to the Grafana implementation of API keys?

Here is an example of the response from the server when a request is made for a key that has expired and is no longer in the UI.

{"message":"Failed to add API key"}

If I delete the key (through either the API or the UI) prior to its expiration, I can create the key again without issue.

When I attempt to view the keys currently present in the system, I receive an empty list.

curl -X GET -H "Content-Type: application/json" http://removed:forsecurity@localhost:3000/api/auth/keys
[]

If I delete the key through the API after expiration (cant do it through the UI as it no longer shows up there), I am able to create the key again.

If the keys do still exist in the database in an expired state, I would like the option of viewing them in the UI. I would also like for them to be reported in the API call to list keys with a field for expiration status.

Please let me know if you need any additional information from me. Hopefully this is not a duplicate issue.

arebackenapi arebackenauth typbug

Most helpful comment

the expired keys should not be taken in account during the api key creation

I think they should / need to. The name is part of a unique index.

Two solutions
1) Automatically clean-up (remove from db) expired keys
2) Show expired keys in list and let org admin remove them manually.

All 3 comments

@5w3rv05 this sounds like a bug to me, but need to verify with the ones implementing it if the implementation was selected due to some special reason.

I have verified it, it's a bug: the expired keys should not be taken in account during the api key creation.
Also, the API call for listing the api keys should optionally return also the expired ones.

the expired keys should not be taken in account during the api key creation

I think they should / need to. The name is part of a unique index.

Two solutions
1) Automatically clean-up (remove from db) expired keys
2) Show expired keys in list and let org admin remove them manually.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tuxinaut picture tuxinaut  ·  3Comments

KlavsKlavsen picture KlavsKlavsen  ·  3Comments

jackmeagher picture jackmeagher  ·  3Comments

calind picture calind  ·  3Comments

victorhooi picture victorhooi  ·  3Comments