Custom Auth Plugin - Panic KeyHash cache not found

Support
1

Running Tyk v5.3.5
502 Bad Gateway

panic serving ...: KeyHash cache not found. You should call `SetKeyHash` before.

We use a custom golang plugin to perform authentication, similar to this example - we set session based on key data we retrieve from Redis.

We disabled key hashing and then saw the error above. It seems to happen when rate limiting is done via Redis which relies on the session’s keyHash value, which itself should apparently be key id / “auth token” when hashing is disabled.

The problem seems to be that that since this is a custom plugin, there is nothing found for “auth token”, as there’s no way to specify the auth_header_name for this mode of authenticating. Is that correct, or are we missing a step for specifying the auth header name in this scenario?

There does seem to be some documentation about setting a metadata token field for this exact reason, but from what I can find it’s only handled when using a CoProcess plugin.

We’ve gotten around this issue by setting the key id of the session manually, but want to understand if we missed a step that would have prevented this, or if the non-CoProcess case should be updated to handle metadata[“token”], etc. Also, although this only came up after disabling key hashing, I believe it could still cause problems when hashing, as the key id is still not set in that case. The hash just becomes something like “000000” which is likely not what’s intended for rate limiting.

2

Hey Tyk Support, can we get some help with this issue?

3

Hi @petermarathas @timothy_park,

Thank you for your post.

The problem seems to be that that since this is a custom plugin, there is nothing found for “auth token”, as there’s no way to specify the auth_header_name for this mode of authenticating. Is that correct, or are we missing a step for specifying the auth header name in this scenario?

An auth_header_name is not required when using custom authentication plugins. In this mode, you are free (and expected) to extract whichever header or request component represents authorization directly in the plugin, and then perform validation there.

As a best practice, we recommend including the KeyID in the session object returned by the plugin. This is the identity the gateway uses to track the request, regardless of hashing configuration, and it is useful for tracking, analytics, rate limiting…
However, we recognize this is omitted in the doc sample.

There does seem to be some documentation about setting a metadata token field for this exact reason, but from what I can find it’s only handled when using a CoProcess plugin.

Correct. The ID extractor applies only to CoProcess/Rich plugins.

Please note that switching the hashing configuration within the same environment is not recommended, as doing so generally invalidates existing auth keys. If you need to change the configuration, it’s better to start a new environment instead of switching in place.

Please let us know if you have further questions, and you may share your plugin code (or relevant parts of it)