Add a name query parameter on /keys or a subroute /keys/name to find key by name

[bidoubiwa]

As per the v0.28.0 the name key will be introduced in the api-keys (see spec).
These have as objective to help create deterministic API keys.

As per my previous discussion: #337 , on adding a name in the keys, it is a good news that it is introduced as it fixes one of the two request made in the discussion.

• Create a name tag
• Find a key using that name

As per my answer in this discussion #443 we still phase the issue that it requires some processing to find a key:

const keys = await client.getKeys();
const key = keys.find(key => key.name === "Admin" );

In my case, this is a process that I use and that I think enters in a lot of automatic API key spreading inside members' spaces on applications.
For example, if I give admin access to a user in my admin dashboard, I would like him to have access to some Meilisearch API keys.
To achieve that, I need to run the code showed above instead of searching with name as a parameter:

const keys = await client.getKeys({ name: "Admin" }); // Query parameter
// Or
const key = await client.getKeyByName({ name: "Admin" }) // Sub route `GET /keys/:name` . I don't think this would work as `/keys/:key` already exists.

[bidoubiwa]

These is the conclusion after a working group on the subject:

Name filter in keys route

The proposition is to add a query parameter to the GET /keys route to be able to filter on the name of a filter.

Example (can be something else):

GET /keys?name=Admin

=> returns

{
    results: [
        {
            name: "Admin", 
            uid: 123123123
            // ...
        }
    ]
}

Currently

There is query parameter within the API to filter on name. It is possible to find by uid or by key.

Questions raised

1. Is it usefull or not
2. Is it a priority
3. Is searching on api key or uid enough

Is it usefull or not

As for now two contributor raised the need to have a filter on name. Some people in Meilisearch showed interest in having this feature.

Having this feature helps the user find their key. While the uid is unique, it is not a human-readable nor a memorable name. Which answers the need of Meilisearch to be simple to use.

There are use-cases where having the possibility to find the key based on a name is useful.

To cut the context into each type of users/team need:

Integration:

Ease to get the keys when testing

Saas:

Dave:

• Nice to have in terms of UX
• Confirmed with the rest of the team — the ability for us to query for a key is not a requirement for the cloud. It MAY become required if it ends up being the only way we can get a valid working key (ie the Master Key behaviour changes). But if we assume we always have access to a known working key, we do not ALSO need the ability to query for keys

Documentation:

Asked Tommy:

• Nice to have
• think it might be useful in some use-cases but does not have an example

User experience

• Nice to have
• Not having the filter is implying that the user is in any case going to look at the keys with human eyes and then copy paste the key.Whereas if the user want to use the default admin key and fetch it in a programatically way they will need to itterate on every key to find it.

Competitors

Based on what the other databases (with and without front-end api's) are requiring, we can take inspiration in their design choice.

• elasticSearch requests a name field and provides a way to find your key with the name.
• mongoDb requests an apiKeyName, it does not provide a way to get the key by name.
• Algolia does not it appears
• typesense does not
• couchbase uses api key name they provide a way to get the key by name also have names for their apikey
• redis uses api key name, could not find the get route.

Use cases

• In a admin dashboard the possibility to provide to a user the key matching its role automatically. Example I give user A admin access to my dashboard, I automatically require the admin key in Meilisearch and provide it to the user A in its dashboard.
• Calling back-end of the app to have to latest search key to use in the front end. In which case the back end would search on name=search_key for example.

There may be others that we are not aware of.

Is it a priority

Following the above, no. It's nice to have.

Is searching on uid or the key enough

What would be the use-case in which a user would search based on these parameters?
Why would a user want to filter on that and not on name?

@gmourier do you have an opinion on this?

Metrics

Look at the query parameters to see if name is used for filtering.

Poll

In favor of adding the parameter 👍
In favor of delaying it until users ask for it 🚀
In favor of not adding that parameter 🎉

[gmourier]

Hi @bidoubiwa and thanks!

Apart from the fact that it will make life easier for someone who has more than 20 API keys (the default limit on v0.28) and wants to restrict the results of the keys by their name (the field being non-unique), what precise use-case does this serve in the user flow? How many keys do a user have on average? How often do they need to change the value of key within the clients (rotating key) ? (These are rhetorical questions that we would like to know when we decide to give this topic a serious angle).

And more important, what's different from const key = keys.find(key => key.name === "Admin" ); than parsing

results: [
        {
            name: "Admin", 
            uid: 123123123
            // ...
        }
    ]

after having called GET /keys?name=admin

From what I understand it's just a helper to reduce the size of the response but we do not how many keys a user has on average.

If a user doesn't rotate keys, (I think) he will mostly store the value of key in an env var (backend-side) or use the search key in the client code.

We should check the usage of SDKs for /keys it could be interesting.

I don't see much value to pursuit in it (for now).