-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting TYK_GW_HASHKEYFUNCTION changes key format #5558
Comments
Was able to find the description here #1753 |
This also makes the loggin statement useless as the key suffix is always one of the three e.g.
|
Ping on this. I think this breaks the custom key flow: https://community.tyk.io/t/trouble-getting-custom-key-to-work/7616 |
Note that while you can see that tyk generate new key format, it is internal key representation, using it with original value will work just fine. |
Using that original value hasn't worked for me... It seems that the new format is returned by GenerateToken function here: Line 89 in ec7db94
And this format is assumed when searching for the key: Line 171 in ec7db94
IIUC the only way we can revert to the old format is setting gw.GetConfig().HashKeyFunction to "". Let me know if I'm wrong here... |
No it doesn't work. It's not reassuring when even Tyk staff is confused about this |
Branch/Environment/Version
Describe the bug
This is an unexpected and undocumented behaviour
If I only set
TYK_GW_HASHKEYS=true
the keys generated by tyk are of the form:123@example.com1a4704c4c6f8456b9a859041e05a09d6
If I set TYK_GW_HASHKEYFUNCTION to any value (murmur64, murmur128, sha256) the returned key is now a base64 encoded json, e.g.
eyJvcmciOiIxMjNAZXhhbXBsZS5jb20iLCJpZCI6Ijk5NzhkZDk0MGNkMzQ5YmNhZWY3YmQyMDQxNGY3YmMyIiwiaCI6InNoYTI1NiJ9
Which when decoded is
Reproduction steps
Set
TYK_GW_HASHKEYFUNCTION
to any valueActual behavior
Key format changes
Expected behavior
Key format doesn't change
Additional context
This significantly increases the key size, which is a concern given that each API request includes in in the header.
The text was updated successfully, but these errors were encountered: