Note: The free mode does not require a license. See
diff --git a/src/gateway/plan-and-deploy/security/start-kong-securely.md b/src/gateway/plan-and-deploy/security/start-kong-securely.md
index e9209ce3c5b6..a8394b34422e 100644
--- a/src/gateway/plan-and-deploy/security/start-kong-securely.md
+++ b/src/gateway/plan-and-deploy/security/start-kong-securely.md
@@ -41,7 +41,7 @@ admin_gui_session_conf = {"secret":"secret","storage":"kong","cookie_secure":fal
admin_listen = 0.0.0.0:8001, 0.0.0.0:8444 ssl
```
-⚠️**Important:** the Sessions Plugin requries a secret and is configured securely by default.
+⚠️**Important:** the Sessions Plugin requires a secret and is configured securely by default.
* Under all circumstances, the `secret` must be manually set to a string.
* If using HTTP instead of HTTPS, `cookie_secure` must be manually set to `false`.
* If using different domains for the Admin API and Kong Manager, `cookie_samesite` must be set to `off`.
@@ -52,6 +52,9 @@ Learn more about these properties in [Session Security in Kong Manager](/gateway
Set a password for the Super Admin. This environment variable must
be present in the environment where database migrations will run.
+{:.important}
+> **Important**: Setting your Kong password (`KONG_PASSWORD`) using a value containing four ticks (for example, `KONG_PASSWORD="a''a'a'a'a"`) causes a PostgreSQL syntax error on bootstrap. To work around this issue, do not use special characters in your password.
+
```
$ export KONG_PASSWORD=
```
@@ -70,7 +73,7 @@ To add additional Super Admins it is necessary to
## Step 2
-Issue the following command to prepare your datastore by running the Kong migrations:
+Issue the following command to prepare your data store by running the Kong migrations:
```
$ kong migrations bootstrap [-c /path/to/kong.conf]
diff --git a/src/gateway/plugin-development/custom-logic.md b/src/gateway/plugin-development/custom-logic.md
index 5c6417fb9421..8e62dff557d6 100644
--- a/src/gateway/plugin-development/custom-logic.md
+++ b/src/gateway/plugin-development/custom-logic.md
@@ -8,12 +8,12 @@ chapter: 3
> **Note**: This chapter assumes that you are familiar with
[Lua](http://www.lua.org/).
-A {{site.ce_product_name}} plugin allows you to inject custom logic (in Lua) at several
+A {{site.base_gateway}} plugin allows you to inject custom logic (in Lua) at several
entry-points in the life-cycle of a request/response or a tcp stream
-connection as it is proxied by {{site.ce_product_name}}. To do so, the file
+connection as it is proxied by {{site.base_gateway}}. To do so, the file
`kong.plugins..handler` must return a table with one or
more functions with predetermined names. Those functions will be
-invoked by {{site.ce_product_name}} at different phases when it processes traffic.
+invoked by {{site.base_gateway}} at different phases when it processes traffic.
The first parameter they take is always `self`. All functions except `init_worker`
can receive a second parameter which is a table with the plugin configuration.
@@ -28,7 +28,7 @@ kong.plugins..handler
If you define any of the following functions in your `handler.lua`
file you'll implement custom logic at various entry-points
-of {{site.ce_product_name}}'s execution life-cycle:
+of {{site.base_gateway}}'s execution life-cycle:
- **[HTTP Module]** *is used for plugins written for HTTP/HTTPS requests*
@@ -44,9 +44,9 @@ of {{site.ce_product_name}}'s execution life-cycle:
| `log` | [log] | Executed when the last response byte has been sent to the client.
{:.note}
-> **Note:** If a module implements the `response` function, {{site.ce_product_name}} will automatically activate the "buffered proxy" mode, as if the [`kong.service.request.enable_buffering()` function][enable_buffering] had been called. Because of a current Nginx limitation, this doesn't work for HTTP/2 or gRPC upstreams.
+> **Note:** If a module implements the `response` function, {{site.base_gateway}} will automatically activate the "buffered proxy" mode, as if the [`kong.service.request.enable_buffering()` function][enable_buffering] had been called. Because of a current Nginx limitation, this doesn't work for HTTP/2 or gRPC upstreams.
-To reduce unexpected behaviour changes, {{site.ce_product_name}} does not start if a plugin implements both `response` and either `header_filter` or `body_filter`.
+To reduce unexpected behaviour changes, {{site.base_gateway}} does not start if a plugin implements both `response` and either `header_filter` or `body_filter`.
- **[Stream Module]** *is used for Plugins written for TCP and UDP stream connections*
@@ -58,12 +58,12 @@ To reduce unexpected behaviour changes, {{site.ce_product_name}} does not start
| `certificate` | [ssl_certificate] | Executed during the SSL certificate serving phase of the SSL handshake.
All of those functions, except `init_worker`, take one parameter which is given
-by {{site.ce_product_name}} upon its invocation: the configuration of your plugin. This parameter
+by {{site.base_gateway}} upon its invocation: the configuration of your plugin. This parameter
is a Lua table, and contains values defined by your users, according to your
plugin's schema (described in the `schema.lua` module). More on plugins schemas
in the [next chapter]({{page.book.next}}).
-Note that UDP streams don't have real connections. {{site.ce_product_name}} will consider all
+Note that UDP streams don't have real connections. {{site.base_gateway}} will consider all
packets with the same origin and destination host and port as a single
connection. After a configurable time without any packet, the connection is
considered closed and the `log` function is executed.
@@ -83,8 +83,8 @@ considered closed and the `log` function is executed.
## handler.lua specifications
-{{site.ce_product_name}} processes requests in **phases**. A plugin is a piece of code that gets
-activated by {{site.ce_product_name}} as each phase is executed while the request gets proxied.
+{{site.base_gateway}} processes requests in **phases**. A plugin is a piece of code that gets
+activated by {{site.base_gateway}} as each phase is executed while the request gets proxied.
Phases are limited in what they can do. For example, the `init_worker` phase
does not have access to the `config` parameter because that information isn't
@@ -93,13 +93,13 @@ available when kong is initializing each worker.
A plugin's `handler.lua` must return a table containing the functions it must
execute on each phase.
-{{site.ce_product_name}} can process HTTP and stream traffic. Some phases are executed
+{{site.base_gateway}} can process HTTP and stream traffic. Some phases are executed
only when processing HTTP traffic, others when processing stream,
and some (like `init_worker` and `log`) are invoked by both kinds of traffic.
In addition to functions, a plugin must define two fields:
-* `VERSION` is an informative field, not used by {{site.ce_product_name}} directly. It usually
+* `VERSION` is an informative field, not used by {{site.base_gateway}} directly. It usually
matches the version defined in a plugin's Rockspec version, when it exists.
* `PRIORITY` is used to sort plugins before executing each of their phases.
Plugins with a higher priority are executed first. See the
@@ -245,12 +245,12 @@ methods.
Logic implemented in those phases will most likely have to interact with the
request/response objects or core components (e.g. access the cache, and
-database). {{site.ce_product_name}} provides a [Plugin Development Kit][pdk] (or "PDK") for such
+database). {{site.base_gateway}} provides a [Plugin Development Kit][pdk] (or "PDK") for such
purposes: a set of Lua functions and variables that can be used by Plugins to
execute various gateway operations in a way that is guaranteed to be
-forward-compatible with future releases of {{site.ce_product_name}}.
+forward-compatible with future releases of {{site.base_gateway}}.
-When you are trying to implement some logic that needs to interact with {{site.ce_product_name}}
+When you are trying to implement some logic that needs to interact with {{site.base_gateway}}
(e.g. retrieving request headers, producing a response from a plugin, logging
some error or debug information), you should consult the [Plugin Development
Kit Reference][pdk].
@@ -260,7 +260,7 @@ Kit Reference][pdk].
Some plugins might depend on the execution of others to perform some
operations. For example, plugins relying on the identity of the consumer have
-to run **after** authentication plugins. Considering this, {{site.ce_product_name}} defines
+to run **after** authentication plugins. Considering this, {{site.base_gateway}} defines
**priorities** between plugins execution to ensure that order is respected.
Your plugin's priority can be configured via a property accepting a number in
diff --git a/src/gateway/reference/cli.md b/src/gateway/reference/cli.md
index 2a75a1734e10..294c0dab8f4f 100644
--- a/src/gateway/reference/cli.md
+++ b/src/gateway/reference/cli.md
@@ -5,6 +5,7 @@
# the files in https://github.com/Kong/kong/tree/master/autodoc/cli
#
title: CLI Reference
+source_url: https://github.com/Kong/kong/tree/master/autodoc/cli
---
The provided CLI (*Command Line Interface*) allows you to start, stop, and
@@ -132,6 +133,8 @@ The available commands are:
list List executed migrations.
reset Reset the database.
+ The `reset` command erases all of the data
+ in Kong's database and deletes all of the schemas.
migrate-community-to-enterprise Migrates Kong Community entities to
Kong Enterprise in the default
diff --git a/src/gateway/reference/clustering.md b/src/gateway/reference/clustering.md
index 0af61390c768..2ffa8455a833 100644
--- a/src/gateway/reference/clustering.md
+++ b/src/gateway/reference/clustering.md
@@ -78,9 +78,7 @@ This makes Kong clusters **eventually consistent**.
When using Postgres as the backend storage, you can optionally enable
Kong to serve read queries from a separate database instance.
-One of the common use cases of this feature is to deploy Kong with the
-Amazon Aurora service as backend storage. Because Aurora natively supports
-read-only instances, enabling the read-only connection support in Kong
+Enabling the read-only connection support in Kong
greatly reduces the load on the main database instance since read-only
queries are no longer sent to it.
diff --git a/src/gateway/reference/configuration.md b/src/gateway/reference/configuration.md
index 7dcb0cae7bb8..4d5e318b77c4 100644
--- a/src/gateway/reference/configuration.md
+++ b/src/gateway/reference/configuration.md
@@ -5,6 +5,7 @@
# the files in https://github.com/Kong/docs.konghq.com/tree/main/autodoc-conf-ee
#
title: Configuration Reference for Kong Gateway
+source_url: https://github.com/Kong/kong-ee/blob/master/kong.conf.default
---
## Configuration loading
@@ -142,9 +143,9 @@ As always, be mindful of your shell's quoting rules specifying values
containing spaces.
For more details on the Nginx configuration file structure and block
-directives, see https://nginx.org/en/docs/beginners_guide.html#conf_structure.
+directives, see the [Nginx reference](https://nginx.org/en/docs/beginners_guide.html#conf_structure).
-For a list of Nginx directives, see https://nginx.org/en/docs/dirindex.html.
+For a list of Nginx directives, see the [Nginx directives index](https://nginx.org/en/docs/dirindex.html).
Note however that some directives are dependent of specific Nginx modules,
some of which may not be included with the official builds of Kong.
@@ -225,6 +226,12 @@ which must specify an Nginx configuration template. Such a template uses the
the given Kong configuration, before being dumped in your Kong prefix
directory, moments before starting Nginx.
+The following Lua functions are available in the [templating engine][pl.template]:
+
+- `pairs`, `ipairs`
+- `tostring`
+- `os.getenv`
+
The default template for
Kong Gateway can be found by entering the following command on the system
running your Kong instance: `find / -type d -name "templates" | grep kong`. For
@@ -233,7 +240,7 @@ open-source Kong Gateway, you can also see the
The template is split in two
Nginx configuration files: `nginx.lua` and `nginx_kong.lua`. The former is
-minimalistic and includes the latter, which contains everything Kong requires
+minimal and includes the latter, which contains everything Kong requires
to run. When `kong start` runs, right before starting Nginx, it copies these
two files into the prefix directory, which looks like so:
@@ -694,7 +701,7 @@ The list of Common Names that are allowed to connect to the control plane.
Multiple entries may be supplied in a comma-separated string. When not
set, only data planes with the same parent domain as the
control plane cert are allowed to connect.
-
+
This field is ignored if `cluster_mtls` is not set to `pki_check_cn`.
**Default:** none
@@ -738,6 +745,38 @@ node to which telemetry updates will be posted in `host:port` format.
---
+#### data_plane_config_cache_mode
+{:.badge .enterprise}
+
+Data planes can store their config to file system as a backup in case the node
+is restarted or reloaded to faster bring the node in configured state or in case
+there are issues connecting to control plane.
+
+This parameter can be used to control the behavior.
+
+To be used by data plane nodes only: `unencrypted` = stores config cache
+unencrypted `encrypted` = stores config cache encrypted `off` = does not store
+the config cache
+
+**Default:** `unencrypted`
+
+---
+
+#### data_plane_config_cache_path
+{:.badge .enterprise}
+
+The unencrypted config cache is stored by default to Kong `prefix` with a
+filename `config.cache.json.gz`.
+
+The encrypted config cache is stored by default to Kong `prefix` with a
+filename `.config.cache.jwt` Alternatively you can specify path for config cache
+with this parameter, e.g. `/tmp/kong-config-cache`.
+
+**Default:** none
+
+---
+
+
### Hybrid Mode Control Plane section
#### cluster_listen
@@ -3002,9 +3041,12 @@ portal_session_conf = { "cookie_name": "portal_session", \
Developer Portal Auto Approve Access
-When this flag is set to `on`, a developer will automatically be marked as
-"approved" after completing registration. Access can still be revoked through
-the Admin GUI or API.
+When set to `on`, a developer will automatically be marked as "approved" after
+completing registration. Access can still be revoked through Kong Manager or the
+Admin API.
+
+When set to `off`, a Kong admin will have to manually approve the Developer
+using Kong Manager or the Admin API.
**Default:** `off`
@@ -3013,8 +3055,8 @@ the Admin GUI or API.
#### portal_token_exp
{:.badge .enterprise}
-Duration in seconds for the expiration of portal login reset/account validation
-token.
+Duration in seconds for the expiration of the Dev Portal reset password token.
+Default is `21600` (six hours).
**Default:** `21600`
@@ -3027,7 +3069,7 @@ Portal Developer Email Verification.
When enabled Developers will receive an email upon registration to verify their
account. Developers will not be able to use the Developer Portal until they
-verify their account.
+verify their account, even if auto-approve is enabled.
Note: SMTP must be turned on in order to use this feature.
@@ -3046,7 +3088,20 @@ particular workspace.
#### portal_invite_email
{:.badge .enterprise}
-Enable or disable portal_invite_email
+When enabled, Kong admins can invite developers to a Dev Portal by using the
+Invite button in Kong Manager.
+
+The email looks like the following:
+
+```
+Subject: Invite to access Dev Portal
+```
+
+Hello Developer!
+
+You have been invited to create a Dev Portal account at %s.
+
+Please visit `` to create your account.
**Default:** `on`
@@ -3055,7 +3110,23 @@ Enable or disable portal_invite_email
#### portal_access_request_email
{:.badge .enterprise}
-Enable or disable portal_access_request_email
+When enabled, Kong admins specified by `smtp_admin_emails` will receive an
+email when a developer requests access to a Dev Portal.
+
+When disabled, Kong admins will have to manually check the Kong Manager to view
+any requests.
+
+The email looks like the following:
+
+```
+Subject: Request to access Dev Portal
+```
+
+Hello Admin!
+
+`` has requested Dev Portal access for ``.
+
+Please visit `` to review this request.
**Default:** `on`
@@ -3064,7 +3135,22 @@ Enable or disable portal_access_request_email
#### portal_approved_email
{:.badge .enterprise}
-Enable or disable portal_approved_email
+When enabled, developers will receive an email when access to a Dev Portal has
+been approved.
+
+When disabled, developers will receive no indication that they have
+beenapproved. It is suggested to only disable this feature if
+`portal_auto_approve` is enabled.
+
+The email looks like the following:
+
+```
+Subject: Dev Portal access approved
+```
+
+Hello Developer! You have been approved to access ``.
+
+Please visit `` to login.
**Default:** `on`
@@ -3073,7 +3159,29 @@ Enable or disable portal_approved_email
#### portal_reset_email
{:.badge .enterprise}
-Enable or disable portal_reset_email
+When enabled, developers will be able to use the Reset Password flow on a Dev
+Portal and will receive an email with password reset instructions.
+
+When disabled, developers will *not* be able to reset their account passwords.
+Kong Admins will have to manually create new credentials for the Developer in
+the Kong Manager.
+
+The email looks like the following:
+
+```
+Subject: Password Reset Instructions for Dev Portal ``.
+```
+
+Hello Developer,
+
+Please click the link below to reset your Dev Portal password.
+
+``
+
+This link will expire in ``
+
+If you didn't make this request, keep your account secure by clicking the link
+above to change your password.
**Default:** `on`
@@ -3082,16 +3190,96 @@ Enable or disable portal_reset_email
#### portal_reset_success_email
{:.badge .enterprise}
-Enable or disable portal_reset_success_email
+When enabled, developers will receive an email after successfully resetting
+their Dev Portal account password.
+
+When disabled, developers will still be able to reset their account passwords,
+but will not receive a confirmation email.
+
+The email looks like the following:
+
+```
+Subject: Dev Portal password change success
+```
+
+Hello Developer, We are emailing you to let you know that your Dev Portal
+password at `` has been changed.
+
+Click the link below to sign in with your new credentials.
+
+``
**Default:** `on`
---
+#### portal_application_status_email
+{:.badge .enterprise}
+
+When enabled, developers will receive an email when the status changes for their
+application service requests.
+
+When disabled, developers will still be able to view the status in their
+developer portal application page.
+
+The email looks like the following:
+
+```
+Subject: Dev Portal application request ()
+
+Hello Developer,
+We are emailing you to let you know that your request for application access from the
+Developer Portal account at is .
+
+Application:
+Service:
+
+You will receive another email when your access has been approved.
+```
+
+**Default:** `off`
+
+---
+
+#### portal_application_request_email
+{:.badge .enterprise}
+
+When enabled, Kong admins specified by `smtp_admin_emails` will receive an
+email when a developer requests access to service through an application.
+
+When disabled, Kong admins will have to manually check the Kong Manager to view
+any requests.
+
+By default, `smtp_admin_emails` will be the recipients. This can be overriden
+by `portal_smtp_admin_emails`, which can be set dynamically per workspace through
+the Admin API.
+
+The email looks like the following:
+
+ ```
+Subject: Request to access Dev Portal () service from
+
+Hello Admin,
+
+ () has requested application access for .
+
+Requested workspace:
+Requested application:
+Requested service:
+
+Please visit to review this request.
+
+```
+
+**Default:** `off`
+
+---
+
#### portal_emails_from
{:.badge .enterprise}
-The name and email address for the `From` header for portal emails
+The name and email address for the `From` header included in all Dev Portal
+emails.
Example: `portal_emails_from = Your Name `
@@ -3116,6 +3304,19 @@ associated with the account.
---
+#### portal_smtp_admin_emails
+{:.badge .enterprise}
+
+Comma separated list of admin emails to receive portal-related notifications.
+
+If none are set, the values in `smtp_admin_emails` will be used.
+
+Example `admin1@example.com, admin2@example.com`
+
+**Default:** none
+
+---
+
### Admin Smtp Configuration section
@@ -3722,7 +3923,6 @@ to escape the sandbox.
---
-
[Penlight]: http://stevedonovan.github.io/Penlight/api/index.html
[pl.template]: http://stevedonovan.github.io/Penlight/api/libraries/pl.template.html
[templates]: https://github.com/kong/kong/tree/master/kong/templates
diff --git a/src/gateway/reference/external-plugins.md b/src/gateway/reference/external-plugins.md
index a1c52cb6ae1a..4c2e9c4d3de2 100644
--- a/src/gateway/reference/external-plugins.md
+++ b/src/gateway/reference/external-plugins.md
@@ -630,7 +630,7 @@ CMD ["kong", "docker-start"]
[go-pluginserver]: https://github.com/Kong/go-pluginserver
[go-plugins]: https://github.com/Kong/go-plugins
[go-pdk]: https://github.com/Kong/go-pdk
-[kong-pdk]: https://docs.konghq.com/latest/plugin-development/
+[kong-pdk]: /gateway/{{page.kong_version}}/pdk/
[go-hello]: https://github.com/Kong/go-plugins/blob/master/go-hello.go
[kong-js-pdk]: https://github.com/Kong/kong-js-pdk
[kong-python-pdk]: https://github.com/Kong/kong-python-pdk
diff --git a/src/gateway/reference/health-checks-circuit-breakers.md b/src/gateway/reference/health-checks-circuit-breakers.md
index a244e855a354..4fb20e3dcfa8 100644
--- a/src/gateway/reference/health-checks-circuit-breakers.md
+++ b/src/gateway/reference/health-checks-circuit-breakers.md
@@ -235,7 +235,7 @@ in order to re-enable it automatically.
### Enabling active health checks
To enable active health checks, you need to specify the configuration items
-under `healthchecks.active` in the [Upstream object][upstreamobjects] configuration. You
+under `healthchecks.active` in the [Upstream object][upstreamobject] configuration. You
need to specify the necessary information so that Kong can perform periodic
probing on the target, and how to interpret the resulting information.
@@ -347,6 +347,6 @@ upstreams.
[targetobject]: /gateway/{{page.kong_version}}/admin-api#target-object
[addupstream]: /gateway/{{page.kong_version}}/admin-api#add-upstream
[clustering]: /gateway/{{page.kong_version}}/reference/clustering
-[upstreamobjects]: /gateway/{{page.kong_version}}/admin-api#upstream-objects
+[upstreamobject]: /gateway/{{page.kong_version}}/admin-api#upstream-object
[balancercaveats]: /gateway/{{page.kong_version}}/reference/loadbalancing#balancing-caveats
[dnscaveats]: /gateway/{{page.kong_version}}/reference/loadbalancing#dns-caveats
diff --git a/tests/edit_link.test.js b/tests/edit_link.test.js
index e5d122a14345..bcd15a63ef5a 100644
--- a/tests/edit_link.test.js
+++ b/tests/edit_link.test.js
@@ -19,7 +19,7 @@ test.describe("Edit this page link", () => {
title: "/app/ page /latest/",
src: "/gateway/latest/",
expected:
- "https://github.com/Kong/docs.konghq.com/edit/main/app/gateway/2.8.x/index.md",
+ "https://github.com/Kong/docs.konghq.com/edit/main/src/gateway/index.md",
},
{
title: "Single Sourced /latest/",