AdvancedSearchPlugin: every type server boots new Shop API keys are being created

[nicoes]

We are using the AdvancedSearchPlugin for a while now with Google Cloud Run.
Every time the server boots new API keys are created with document.search permissions with the scope set to our collections. While this certainly is safe, it also creates a lot of API keys. Especially since we are booting quite often in the "serverless" set-up.

I think it would be a nice feature to be able to provide a Shop API client key through the Vendure configuration (where env vars can be injected), for the plugin to use.
We would need to set the collections scope to * (to account for new collections being created) but I don't see much risk there in our case.

Is this something that can be added in the suggested way or an alternative?

[michaelbromley]

Hi,

Yes, we should be able to solve this one way or another. I'm not sure I like using the '*' scope though. Maybe there's better way to do it. E.g:

1. On bootstrap, we check for a shopKey option passed in from the config (i.e. via env var)
2. We fetch all keys from Typesense
3. We compare the shopKey value to find the matching key.
4. We compare the collections property of the matched key against the configured collections.
5. If it matches, carry on.
6. If not, then the current key needs to be updated. We generate a new key and then somehow we need to get the value to you so you can update your config. E.g. we can prominently log it, or maybe provide some other mechanism to persist it somewhere. Not sure about that part yet.

Alternatively, we could just get all the keys from Typesense and then compare the collections with the currently-configured collections and then just re-use any key that matches. That would be even simpler and would mean that we only create a new key when you add a new collection.

[nicoes]

Yeah sounds more sophisticated already. I was thinking of the quickest solution but it has it's flaws indeed.
Appreciating the solutions proposed. Still doesn't feel 100% right somehow. Coining an alternative in the line of your ideas:

1. Provide an typesense shopKeyAccessSecret through env vars
2. Create a shopKey in typesense, hash it with shopKeyAccessSecret and save it in the db as typesenseShopKey.
3. On next run, look up typesenseShopKey, unhash it with shopKeyAccessSecret an see if collections still match with configured collections.
4. If it matches carry on with the unhashed shopKey
5. If it doesn't match the current key needs to be updated and the hashed version needs to be updated in the db.

Then the user is not bothered with needing to update the config and we persist the shopKey safely to the db.

What do you think?

[michaelbromley]

Just published v1.4.0 which implements the above idea to prevent new API keys being generated.

To enable, set the new shopApiKeySecret to some string value, and you'll need to then run a DB migration because it will add a custom field to the GlobalSettings entity.