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?

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

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.

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('');

cc @Haroenv @maxiloc

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

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!

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!

sorry for the delay @Haroenv. our use case is very similar to @CSNWEB's - we apply a long set of filters because the permissions around what any particular user can search for and access are very granular

How long is the URL, and where does it cause problems @jackmccloy?

We also encounter the same error when switching to the client v4.
On our end, we encounter the Header too large ApiError and have to use the proposed workaround by explicitly removing the api key from the headers:

delete index.transporter.headers['x-algolia-api-key'];

hey @jpreynat, how long was your URL and at which point did you get the error, was that from the Algolia backend?

Hi @Haroenv, it wasn't an issue with the URL but the size of the header.

I got this issue as soon as I switched from v3 to v4 when calling client.search().

Actually, the workaround is working from our Node backend, but from the frontend, no results are returned anymore, so this is definitely problematic for us.
I've tried passing the api key in the query parameters, but this time I end with the request uri is too large and status 414 error. The full URI with the api key is 8660 characters long.

What throws this error?

Just fetching the URL with everything in the query parameters returns this error.

I've looked it up, and the error indeed comes from nginx, but sending it via the url or via headers doesn't make a difference I think, the default in nginx (as far as I can tell we use the default for this) https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers is 8k, so an api key that's so long will still error, even if it's sent by headers @jpreynat.

I'd have to check, but you can make the client force sending auth via the headers https://codesandbox.io/s/upbeat-tu-4juop?file=/src/app.js. I think that still would throw the nginx error

import algoliasearch from 'algoliasearch';
import { AuthMode } from '@algolia/client-common';

const client = algoliasearch('latency', '6be0576ff61c053d5f9a3225e2a90f76', {
  authMode: AuthMode.WithinHeaders, // authMode: 1
});
const index = client.initIndex('instant_search');

docs for authMode: https://www.algolia.com/doc/api-client/advanced/configure-the-client/javascript/?client=javascript#auth-mode

Thanks for the details @Haroenv.

Do you have any idea why this works with the v3 client though? We’re using the exact same keys in both cases.

If this can’t be modified on your end, what would you recommend us to do then?

Thanks again for your help 🙏

v3 had the ability to put the key in the body instead of the header in case the api key was too long.

Thanks for chiming in @maxiloc, in v3 this indeed happened automatically, while in v4 there's a specific option for it (authMode). Did you try it with the withinHeaders method @jpreynat? I might have misread the error message in the nginx spec and it allows longer headers than uri itself. The documentation isn't very elaborate on that part.

Oh, I read it right now, I forgot it could go in the body of a request as well, and that likely has a different limit, the workaround given by @nunomaduro in #1035 (comment) should still work in that case I think

Thanks for clarifying this @maxiloc 👍

@Haroenv I didn't try the withinHeaders method yet. But if the headers in nginx are limited to 8k characters, I'm scared we might hit the limit sometimes since my URL with the querystring was larger than this. I'll give it a try thought.

When trying the workaround, it worked when using Node, but when using the bundled JS library in the browser, I received only empty results with the same key, so there might be some other changes to do in this case.

@Haroenv @nunomaduro one more request to add withBody authMode. What is the reason why it's still the issue and not merged?

@jpreynat how have you fixed that issue on your end?