discussion: very long secured api-keys cause problems while searching

[chrisstaudt]

We use very long secured API keys, which works fine with the 3.x version of the package but version 4.x breaks this, as the key seems to be appended to the URL regardless how long it is. It basically reintroduces this: #319. I think version 4 should also sent long api keys via the POST body.

[nunomaduro]

We have added this section into to the docs:

Keep in mind that the more limitations you set, the longer the key. You might face network limitations with a key longer than 500 characters, so consider this when adding restrictions.

At the moment, we don't have plans of having this feature on the 4.x. What's your use case?

[chrisstaudt]

As the data a user can access in our app is highly individualized, we need to apply a long set of filters in order to get only results that are suitable for the user. As the other issue shows other people face this issue as well. It would be great if you could reconsider this. At least you should add it to the upgrade guide that this breaks when upgrading from 3.x to 4.x

[nunomaduro]

I see. For the moment, if you heavily rely on this feature, I propose you keep using the 3.x. If we receive enough demand, we will reconsider this. Let's keep the issue open for a while.

[nunomaduro]

Meanwhile, a non-official workaround that is just here for investigation proposes. 🍛

import algoliasearch from 'algoliasearch/lite';

const appId = 'YourApplicationID';
const apiKey = 'YourSecuredApiKey';
const index = algoliasearch(appId, apiKey).initIndex('index_name');

// Workaround start
delete index.transporter.queryParameters['x-algolia-api-key'];
const read = index.transporter.read;
index.transporter.read = (request, requestOptions) => {
  return read(request, { apiKey, ...requestOptions });
};
// Workaround end

const results = await index.search('');

[nunomaduro]

cc @Haroenv @maxiloc

[nunomaduro]

We added a note about this limitation: https://www.algolia.com/doc/api-reference/api-methods/generate-secured-api-key/#about-this-method.

[jackmccloy]

I see. For the moment, if you heavily rely on this feature, I propose you keep using the 3.x. If we receive enough demand, we will reconsider this. Let's keep the issue open for a while.

hey @nunomaduro, i'm bumping into this issue too and just saw your note that it'll be a "wontfix" unless it receives more demand. our situation seems to be identical to @CSNWEB's - we apply a long set of filters, generating very long secured API keys. I imagine this is also true for many use cases where search needs to be highly personalized.

it would be great if this limitation was removed so we can upgrade from v3 to v4. thanks!

[Haroenv]

Hi @jackmccloy, so far we indeed have seen this issue only very sporadically, which is why it's not been fixed yet. From my research, I can see that URLs more have a 2000± character limit (not 500) (see https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers). Could you explain the exact use case and where it gets blocked? Thanks!