Whether consumer-restriction can be matched with a re or prefix

[MorganArthur]

Description

In the use of consumer-restriction, we need to configure a large number of whitelists in the route. Currently, more than 400 whitelists need to be configured. Therefore, I would like to consult whether consumer-restriction can be whitelisted in the form of re or prefix matching.

Environment

• APISIX version (run apisix version):2.13
• Operating system (run uname -a):
• OpenResty / Nginx version (run openresty -V or nginx -V):
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info):
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[tokers]

What about introducing the consumer group concept?

[tokers]

So that we can only need to configure the group in the plugin.

[MorganArthur]

That's a good idea

[tokers]

So we can add a new field group in the consumer-restriction plugin and it will apply to all consumers in this group.

In such a case, we have two options to support the group:

1. Add a dedicated concept consumer_group, and we can only bind consumers to existent group;
2. Organize the group mapping inside APISIX and make a loose bind relationship, which means we can configure the group field in the consumer without limitation.

[tzssangglass]

I have a question, what is this scene? How did you bind the consumer in APISIX to the concept of what entity in your scenario.

[MorganArthur]

Our system provides an interface service externally. Applications registered on our platform can access the interface provided by us according to the authentication information of the application. We hope to respond to the flow limiting control for each application.

[tzssangglass]

Can you give the desensitized consumer and route configuration.

I don't think using consumer_group seems to solve the problem of having to configure a lot of whitelists. Since you thought of using regulars, why not create routes with regulars and do restrictions based on those routes?

Typically, we will do something with the request only after matching the route. Rather than roughly matching a large number of requests (such as use /* as router uri) and then differentiating them based on uri.

[MorganArthur]

Maybe my description is not exact, but the actual usage is that we only have two kinds of interfaces for users of our system to use, and we want to set different traffic limiting rules for different users. The interface has been provided and used for a long time. Now we want to add a gateway to add some interface restrictions. My understanding is that if we want to create a route through RE to impose restrictions, we will have to change the exposed interface, but we don't want to change the interface provided

[tokers]

I don't think using consumer_group seems to solve the problem of having to configure a lot of whitelists. Since you thought of using regulars, why not create routes with regulars and do restrictions based on those routes?

What are regulars? 🤔

[tokers]

Maybe my description is not exact, but the actual usage is that we only have two kinds of interfaces for users of our system to use, and we want to set different traffic limiting rules for different users. The interface has been provided and used for a long time. Now we want to add a gateway to add some interface restrictions. My understanding is that if we want to create a route through RE to impose restrictions, we will have to change the exposed interface, but we don't want to change the interface provided

I'm sorry but what is 'RE`?

[tzssangglass]

Maybe my description is not exact, but the actual usage is that we only have two kinds of interfaces for users of our system to use, and we want to set different traffic limiting rules for different users. The interface has been provided and used for a long time. Now we want to add a gateway to add some interface restrictions. My understanding is that if we want to create a route through RE to impose restrictions, we will have to change the exposed interface, but we don't want to change the interface provided

After thinking about it for a while, I realized that consumer_group is a viable solution. Because here we are looking for a group of consumers.

[tzssangglass]

Maybe my description is not exact, but the actual usage is that we only have two kinds of interfaces for users of our system to use, and we want to set different traffic limiting rules for different users. The interface has been provided and used for a long time. Now we want to add a gateway to add some interface restrictions. My understanding is that if we want to create a route through RE to impose restrictions, we will have to change the exposed interface, but we don't want to change the interface provided

I'm sorry but what is 'RE`?

sorry, ignore it, I had misunderstood it before.