Introduce a wildcard * pattern expression on the indexes parameter when creating an API Key.

[gmourier]

It is not possible to specify access to all indexes that start with a specific string at API key creation.

The idea is to make it possible to write "indexes": ["foo_*"] so that the API key created can access all indexes starting with foo.

It could make the creation of an API key easier and faster in case several indexes are prefixed by a fixed string and need to be accessible by the same key.

It would avoid having to specify "indexes": ["foo_1", "foo_2", "foo_3", ...]

We would like to know why you have this need (aka why do you prefix indexes name?) 😇

Feel free to describe your workflow in detail. Thank you very much.

[Carlwirkus]

This is a feature I would like to support multi-tenancy. The idea being that each tenant is issued a key with access to the indexes for their unique tenant prefix. Without this, the indexes of each key need to updated as new indexes are added.

[gmourier]

Thank you, @Carlwirkus. Do your tenants need to be able to do other operations than searching on their indexes?

Asking this because you may have missed https://docs.meilisearch.com/learn/security/tenant_tokens.html#multitenancy-and-tenant-tokens. It's possible to generate dedicated user tokens to restrict their access to documents in the same index so you may not need to have dedicated indexes for a tenant?

In any case, this wildcard prefix seems useful to make all tenant tokens automatically benefit from the indexes that the signing API key being used to generate the tokens.

[Carlwirkus]

Yes, only searching for the moment.

[Carlwirkus]

My multi tenancy setup has a database for each tenant and the tenant id does not exist on the index data. I could add the tenant id to the index and make use of the search. However, there would be privacy concerns around having a single index with multiple tenants data so I've elected to keep them as isolated as possible.

[gmourier]

Thanks @Carlwirkus

[FrittenKeeZ]

We really need this feature for our setup, as we mostly use Laravel with Scout, which creates indexes dynamically, and we don't know what indexes are needed up front when creating API keys for each project.

[gmourier]

Hey @FrittenKeeZ 👋

Do you have some sort of format for your index names? Can you share an example of how you will create an API Key with your use-case?

Thanks!

[FrittenKeeZ]

@gmourier we prefix our Scout indexes with project name and environment, so we'd have configuration like:

• SCOUT_PREFIX=comwell-stage-
• SCOUT_PREFIX=comwell-prod-

Resulting users indexes would be comwell-stage-users and comwell-prod-users respectively, so indexes configuration would be ['comwell-stage-*'] and ['comwell-prod-*'] for their respective API keys.

Does that make sense to you?

[gmourier]

Yes, @FrittenKeeZ, it makes sense! Thanks a lot for explaining it.

[gmourier]

Hello, everyone following this discussion 👋

We have just released the first RC (release candidate) of Meilisearch containing this new implementation!
You can test it by using

• the release assets
• the Meilisearch Docker image

docker run -it --rm -p 7700:7700 -v $(pwd)/meili_data:/meili_data getmeili/meilisearch:v1.1.0-rc.0

You are welcome to communicate any feedback about this new implementation in this discussion.

If you encounter any bugs, please report them here.
Thanks in advance for your help and your involvement in Meilisearch ❤️

🎉 Official and stable release containing this change will be available on 3rd April 2023

⚠️ RC (release candidates) are not recommended for production