public-api
#
DescriptionThe public-api
plugin is used to enhance the plugin public API access control.
When current users develop custom plugins, they can register some public APIs for fixed functionality, such as the /apisix/plugin/jwt/sign
API in jwt-auth
. These APIs can only apply limited plugins for access control (currently only ip-restriction
) by way of plugin interceptors.
With the public-api
plugin, we put all public APIs into the general HTTP API router, which is consistent with the normal Route registered by the user and can apply any plugin. The public API added in the user plugin is no longer expose by default by APISIX, and the user has to manually configure the Route for it, the user can configure any uri and plugin.
#
AttributesName | Type | Requirement | Default | Valid | Description |
---|---|---|---|---|---|
uri | string | optional | "" | The uri of the public API. When you set up the route, you can use this to configure the original API uri if it is used in a way that is inconsistent with the original public API uri. |
#
ExampleWe take the jwt-auth
token sign API as an example to show how to configure the public-api
plugin. Also, the key-auth
will be used to show how to configure the protection plugin for the public API.
#
PrerequisitesThe use of key-auth and jwt-auth requires the configuration of a consumer that contains the configuration of these plugins, and you need to create one in advance, the process will be omitted here.
#
Basic Use CaseFirst we will setup a route.
$ curl -X PUT 'http://127.0.0.1:9080/apisix/admin/routes/r1' \
-H 'X-API-KEY: <api-key>' \
-H 'Content-Type: application/json' \
-d '{
"uri": "/apisix/plugin/jwt/sign",
"plugins": {
"public-api": {}
}
}'
Let's test it.
$ curl 'http://127.0.0.1:9080/apisix/plugin/jwt/sign?key=user-key'
It will respond to a text JWT.
#
Customize URILet's setup another route.
$ curl -X PUT 'http://127.0.0.1:9080/apisix/admin/routes/r2' \
-H 'X-API-KEY: <api-key>' \
-H 'Content-Type: application/json' \
-d '{
"uri": "/gen_token",
"plugins": {
"public-api": {
"uri": "/apisix/plugin/jwt/sign"
}
}
}'
Let's test it.
$ curl 'http://127.0.0.1:9080/gen_token?key=user-key'
It will still respond to a text JWT. We can see that users are free to configure URI for the public API to match.
#
Protect RouteLet's modify the last route and add key-auth
authentication to it.
$ curl -X PUT 'http://127.0.0.1:9080/apisix/admin/routes/r2' \
-H 'X-API-KEY: <api-key>' \
-H 'Content-Type: application/json' \
-d '{
"uri": "/gen_token",
"plugins": {
"public-api": {
"uri": "/apisix/plugin/jwt/sign"
},
"key-auth": {}
}
}'
Let's test it.
$ curl -i 'http://127.0.0.1:9080/gen_token?key=user-key'
-H "apikey: test-apikey"
HTTP/1.1 200 OK
# Failed request
$ curl -i 'http://127.0.0.1:9080/gen_token?key=user-key'
HTTP/1.1 401 UNAUTHORIZED
It will still respond to a text JWT. If we don't add apikey
to the request header, it will respond with a 401 block request. In this way, we have implemented a plugin approach to protect the public API.