The API_KEY is already unique for different consumers. No two users have the same api_key.

The API_KEY is already unique for different consumers. No two users have the same api_key.

Hi,
I realy created 2 consumer with the same API KEY, you can try this

The consumer username should be unique

username required unique but API Key also, because if API Key not unique for all user how about your detect user A with user B.

What happens when the username is unique but the API Key is duplicate, then determining which user is calling is impossible

username required unique but API Key also, because if API Key not unique for all user how about your detect user A with user B.

What happens when the username is unique but the API Key is duplicate, then determining which user is calling is impossible

@dvdieu You are right, if there are duplicate API keys, it is impossible to identify different consumers.
I don't have a good proposal on how to solve it yet, because Apache APISIX uses etcd as storage instead of a relational database, and it's not easy to determine if there are duplicates. What do you think?

You are right, if there are duplicate API keys, it is impossible to identify different consumers.
I don't have a good proposal on how to solve it yet, because Apache APISIX uses etcd as storage instead of a relational database, and it's not easy to determine if there are duplicates. What do you think?

i think
local client = etcd.client({host = etcd_host, port = etcd_port})
local response, err = client:get(key)
if err then
return false
end
if response.count > 1 then
return true
else
return false
end

for scaling we can using redis for check before insert to ectd

You are right, if there are duplicate API keys, it is impossible to identify different consumers.
I don't have a good proposal on how to solve it yet, because Apache APISIX uses etcd as storage instead of a relational database, and it's not easy to determine if there are duplicates. What do you think?

i think local client = etcd.client({host = etcd_host, port = etcd_port}) local response, err = client:get(key) if err then return false end if response.count > 1 then return true else return false end

for scaling we can using redis for check before insert to ectd

If this judgment logic can be added when adding API key instead of processing client requests, it is good for me

Please update this bug