Get consumer by username is not found when length of username > 36

[cuongnc5]

Summary

• Kong version ('Latest`)
• A concise summary of the bug.

Steps To Reproduce

1. Create consumer with username (length = 37 charaters): 40af65f4-2a40-4ab2-bb9d-bf1ee39ecab3
2. Get consumer by username http://localhost:8001/consumers/40af65f4-2a40-4ab2-bb9d-bf1ee39ecab3 Now: Result always "message": "Not found" Expected: consumer info with username 40af65f4-2a40-4ab2-bb9d-bf1ee39ecab3

[gszr]

Hi @cuongnc5,

Welcome to the Kong community.

Thanks for reporting, I can reproduce on my end.

[jeremyjpj0916]

Interesting, using a uuid as the consumer username must be tricking Kong under the hood 😄 . Because the URI of the admin api endpoint expects a username or uuid, but since passing a uuid(which you set as a username) its doing a uuid lookup and not finding that uuid as a primary id in db when it would need to fall back on looking that id up by username field if their admin APIs maintain the way they are designed, probably decision tree now just parses the inbound URI field to see if its in a UUID format to see if its a primary id lookup vs username.

[gszr]

Interesting, using a uuid as the consumer username must be tricking Kong under the hood 😄 . Because the URI of the admin api endpoint expects a username or uuid, but since passing a uuid(which you set as a username) its doing a uuid lookup and not finding that uuid as a primary id in db when it would need to fall back on looking that id up by username field if their admin APIs maintain the way they are designed, probably decision tree now just parses the inbound URI field to see if its in a UUID format to see if its a primary id lookup vs username.

This is precisely what happened @jeremyjpj0916 😃 We are working on a fix.

[cuongnc5]

Interesting, using a uuid as the consumer username must be tricking Kong under the hood 😄 . Because the URI of the admin api endpoint expects a username or uuid, but since passing a uuid(which you set as a username) its doing a uuid lookup and not finding that uuid as a primary id in db when it would need to fall back on looking that id up by username field if their admin APIs maintain the way they are designed, probably decision tree now just parses the inbound URI field to see if its in a UUID format to see if its a primary id lookup vs username.

This is precisely what happened @jeremyjpj0916 😃 We are working on a fix.

I'm sorry, I mistakenly pressed the close button and I used uuid as the username. I'm not trying to trick Kong : EASY Because before integrating kong into the system, we had a user table - it linked to many other tables by userId. So I used userId as username on Kong. Maybe I was wrong. I should reconsider using username. :D Many thanks!

[bungle]

I am not sure if that is a bug or by design. If the url is uuid we look by consumer id. Otherwise we look by endpoint key. I think that is pretty good as is and consistent with entities that do not have endpoint key (e.g. plugins), perhaps better documentation could be done. Please remember that when you do:

http put :8001/consumers/40af65f4-2a40-4ab2-bb9d-bf1ee39ecab3 username=jack

It will use 40af65f4-2a40-4ab2-bb9d-bf1ee39ecab3 as an id.

I would use custom_id as 40af65f4-2a40-4ab2-bb9d-bf1ee39ecab3 in that case, not the username, and custom_id cannot be used as endpoint key as we only support single endpoint key in addition to id.

The id is primary thing that we support with urls, the endpoint key is secondary to that.

[bungle]

Alternative would be to add support for all unique fields, e.g.:

http get :8001/consumers/username:40af65f4-2a40-4ab2-bb9d-bf1ee39ecab3

or something like that. We already also do support this:

http get :8001/consumers?custom_id=<custom-id>

That is not supported with username though.

[DiySane]

@gszr I am interested in the issue. Would love to have bit of an insight.

[StarlightIbuki]

Dear contributor, We're closing this issue as there hasn't been any update to it for a long time. If the issue is still relevant in the latest version, please feel free to reopen it. We're more than happy to revisit it again. Your contribution is greatly appreciated! Please have a look at our pledge to the community for more information. Sincerely, Kong Gateway Team

[Silviu-Nicola]

Somebody should fix this ...

[brucetony]

This is very much still an issue and would like to see this reopened and revisited