Background
Current APISIX users can register public APIs when developing plugins, such as the sign API in the jwt-auth plugin and the login and other API in the wolf-rbac plugin. In the current design, users can control their access through API interceptor, which currently only support IP restrictions via the ip-restriction plugin and cannot apply more complex access patterns.
Therefore, we designed the public-api plugin, which incorporates the APIs from user plugins into the general HTTP request processing flow and supports the configuration of all plugins currently supported by APISIX.
Scheme
Configure schema
| Name |
Type |
Requirement |
Default |
Description |
| uri |
string |
optional |
|
The URI registered for this public API (used when the user customizes the URI of the plugin's public API, i.e. a different URI than the one defined for the public API is used in general HTTP routing) |
Imagine a scenario where we have a custom-auth plugin that provides a login interface at /apisix/custom-auth/login, and we want to provide this API at /login, so we can create a route with uri = /login and configure it with the public-api plugin where the uri will be configured as /apisix/custom-auth/login, so that when the user accesses /login, the request will be forwarded to the headler in the plugin.
Principle
Currently, APISIX generates a special radixtree to handle route matching for the public API registered in the user's plugin, which is independent of the general HTTP request processing flow and takes precedence over matching. So we can't apply all the plugins to it, we need to adapt those plugins one by one.
Therefore, we need to modify the flow so that the general HTTP request route is matched before the plugin‘s public API, and when a route is matched and it has the public-api plugin enabled, it will call the appropriate plugin public API headler based on the plugin configuration or the URI of the current request.
This allows us to apply any plugin to a plugin public API and also allows the user to decide whether to allow the client to access a public API and what URI to use.
Other
What are your ideas?
Background
Current APISIX users can register public APIs when developing plugins, such as the
signAPI in thejwt-authplugin and theloginand other API in thewolf-rbacplugin. In the current design, users can control their access through API interceptor, which currently only support IP restrictions via theip-restrictionplugin and cannot apply more complex access patterns.Therefore, we designed the
public-apiplugin, which incorporates the APIs from user plugins into the general HTTP request processing flow and supports the configuration of all plugins currently supported by APISIX.Scheme
Configure schema
Imagine a scenario where we have a
custom-authplugin that provides a login interface at/apisix/custom-auth/login, and we want to provide this API at/login, so we can create a route withuri = /loginand configure it with thepublic-apiplugin where theuriwill be configured as/apisix/custom-auth/login, so that when the user accesses/login, the request will be forwarded to the headler in the plugin.Principle
Currently, APISIX generates a special radixtree to handle route matching for the public API registered in the user's plugin, which is independent of the general HTTP request processing flow and takes precedence over matching. So we can't apply all the plugins to it, we need to adapt those plugins one by one.
Therefore, we need to modify the flow so that the general HTTP request route is matched before the plugin‘s public API, and when a route is matched and it has the
public-apiplugin enabled, it will call the appropriate plugin public API headler based on the plugin configuration or the URI of the current request.This allows us to apply any plugin to a plugin public API and also allows the user to decide whether to allow the client to access a public API and what URI to use.
Other
What are your ideas?