diff --git a/tyk-docs/content/plugins.md b/tyk-docs/content/plugins.md index 4dfe8e8f3a..338fa284b1 100755 --- a/tyk-docs/content/plugins.md +++ b/tyk-docs/content/plugins.md @@ -9,20 +9,28 @@ aliases: - /customise-tyk/plugins/ --- -Tyk supports the use of the following plugins to extend Tyk functionality: +Tyk supports the use of custom plugins to extend Tyk functionality. -* [Python, Lua, gRPC (Rich Plugins)]({{< ref "plugins/supported-languages/rich-plugins" >}}) -* [JavaScript Plugins]({{< ref "plugins/supported-languages/javascript-middleware" >}}) (JSVM Middleware) -* [Golang native plugins]({{< ref "plugins/supported-languages/golang" >}}) +Plugins can be executed in the **following order** inside the following areas of the [API Request Lifecycle]({{< ref "concepts/middleware-execution-order" >}}): -inside the following areas of the API Request Lifecycle - -* [Authentication Plugins]({{< ref "plugins/auth-plugins" >}}) -* [Request Plugins]({{< ref "plugins/request-plugins" >}}) -* [Response Plugins]({{< ref "plugins/response-plugins" >}}) +* [Pre (Request) Plugin]({{< ref "plugins/plugin-types/request-plugins" >}}) +* [Authentication Plugin]({{< ref "plugins/plugin-types/auth-plugins/auth-plugins" >}}) +* [Post-Auth (Request) Plugin]({{< ref "plugins/plugin-types/request-plugins" >}}) +* [Post (Request) Plugin]({{< ref "plugins/plugin-types/request-plugins" >}}) +* [Response Plugin]({{< ref "plugins/plugin-types/response-plugins" >}}) +* [Analytics Plugin]({{< ref "plugins/plugin-types/analytics-plugins" >}}) ### Plugin Caveats * They must run as a single process. -* The plugins used *must* be specified in an API definition and are not global across APIs. +* To apply a custom plugin to an API you must modify the API definition and add the plugin information to one of the areas of the API Request Lifecycle mentioned above. * They must manage API-specific cases in the same process, only one CoProcess will be managed by a Tyk Instance. + +### Language Support + +Tyk recommends using Go plugins for performance, flexibility, and nativity reasons (All Tyk components are written in Go). + +The following languages are supported for custom plugins: +* [Golang native plugins]({{< ref "plugins/supported-languages/golang" >}}) - fast, native performance +* [JavaScript Plugins]({{< ref "plugins/supported-languages/javascript-middleware" >}}) (JSVM Middleware) - simple with limited direct API when performance not important (same with Python / Lua) +* [Python, Lua, gRPC (Rich Plugins)]({{< ref "plugins/supported-languages/rich-plugins" >}}) - ultimate flexibility in the language of implementation, however, there are some performance and management overheads when compared to native GoLang plugins diff --git a/tyk-docs/content/plugins/get-started-selfmanaged/deploy.md b/tyk-docs/content/plugins/get-started-selfmanaged/deploy.md new file mode 100644 index 0000000000..bc9a8ef72a --- /dev/null +++ b/tyk-docs/content/plugins/get-started-selfmanaged/deploy.md @@ -0,0 +1,120 @@ +--- +date: 2017-03-24T15:45:13Z +title: Task 3 - Automating Your Build Process +menu: + main: + parent: "Get Started with Custom Plugins" +weight: 10 +--- + +It's very important to automate the deployment of your infrastructure. + +Ideally, you store your configurations and code in version control, and then through a trigger, have the ability to deploy everything automatically into higher environments. + +With custom plugins, this is no different. + +To illustrate this, we can look at the GitHub Actions of the [example repo][0]. + +We see that upon every pull request, a section of steps are taken to "Build, [Bundle]({{< ref "plugins/how-to-serve-plugins/plugin-bundles" >}}), Release Go Plugin". + +Let's break down the [workflow file][1]: + + +## 1. Compiling the Plugin + +We can see the first few steps replicate our first task, bootstrapping the environment and compiling the plugin into a binary format. + +```make + steps: + - uses: actions/checkout@v3 + + - name: Copy Env Files + run: cp tyk/confs/tyk_analytics.env.example tyk/confs/tyk_analytics.env + + - name: Build Go Plugin + run: make go-build +``` + +We can look at the [Makefile][2] to further break down the last `go-build` command. + +## 2. Bundle The Plugin + +The next step of the workflow is to "[bundle]({{< ref "plugins/how-to-serve-plugins/plugin-bundles" >}})" the plugin. + +``` +- name: Bundle Go Plugin + run: docker-compose run --rm --user=1000 --entrypoint "bundle/bundle-entrypoint.sh" tyk-gateway +``` + +This command generates a "bundle" from the sample Go plugin in the repo. + +{{< note success >}} +**Note** + +For added security, please consider signing your [bundles]({{< ref "plugins/how-to-serve-plugins.md#global-parameters" >}}), especially if the connection between the Gateways and the Bundler server traverses the internet. + +{{< /note >}} + + +Custom plugins can be "bundled", (zipped/compressed) into a standard format, and then uploaded to some server so that they can be downloaded by the Gateways in real time. + +This process allows us to decouple the building of our custom plugins from the runtime of the Gateways. + +In other words, Gateways can be scaled up and down, and pointed at different plugin repos very easily. This makes it easier to deploy Custom plugins especially in containerized environments such as Kubernetes, where we don't have to worry about persistent volumes. + +You can read more about plugin bundles [here][3]. + +## 3. Deploy The Plugin + +Next step of the workflow is to publish our bundle to a server that's reachable by the Gateways. + +```make +- name: Upload Bundle + uses: actions/upload-artifact@v3 + with: + name: customgoplugin.zip + path: tyk/bundle/bundle.zip + + - uses: jakejarvis/s3-sync-action@master + with: + args: --acl public-read --follow-symlinks + env: + AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }} + AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} + AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} + AWS_REGION: 'us-east-1' + SOURCE_DIR: 'tyk/bundle' +``` + +This step uploads the Bundle to both GitHub and an AWS S3 bucket. Obviously, your workflow will look slightly different here. + +{{< note success >}} +**Note** + +For seamless deployments, take a look at multi-version [plugin support]({{< ref "plugins/supported-languages/golang.md#upgrading-tyk" >}}) to enable zero downtime deployments of your Tyk Gateway installs + +{{< /note >}} + +### 4. Configure the Gateway + +In order to instruct the Gateway to download the bundle, we need two things: + +1. The root server - The server which all bundles will be downloaded from. This is set globally in the Tyk conf file [here]({{< ref "tyk-oss-gateway/configuration#enable_bundle_downloader" >}}). + +2. The name of the bundle - this is generated during your workflow usually. This is defined at the API level (this is where you declare Custom plugins, as evident in task 2) + +The field of the API Definition that needs to be set is `custom_middleware_bundle`. + +## Summary + +That's it! + +We've set up our dev environment, built, compiled, a Custom Go plugin, loaded onto a Tyk Gateway, and tested it by sending an API request. Finally, we've talked about deploying a Bundle in a production grade set up. + +Have a look at our [examples repo][4] for more inspiration. + +[0]: https://github.com/TykTechnologies/custom-go-plugin/actions +[1]: https://github.com/TykTechnologies/custom-go-plugin/blob/master/.github/workflows/makefile.yml +[2]: https://github.com/TykTechnologies/custom-go-plugin/blob/master/Makefile#L59 +[3]: https://github.com/TykTechnologies/custom-go-plugin#deploying-the-go-plugin +[4]: https://github.com/TykTechnologies/custom-plugin-examples \ No newline at end of file diff --git a/tyk-docs/content/plugins/get-started-selfmanaged/get-started.md b/tyk-docs/content/plugins/get-started-selfmanaged/get-started.md new file mode 100644 index 0000000000..062cac7424 --- /dev/null +++ b/tyk-docs/content/plugins/get-started-selfmanaged/get-started.md @@ -0,0 +1,22 @@ +--- +date: 2017-03-24T15:45:13Z +title: Get Started with Custom Plugins +menu: + main: + parent: "Custom Plugins" +weight: 10 +--- + +This section takes you through the development process of creating a Custom Go Plugin. + +At the end of this process you will have a Tyk environment running locally and a simple Go plugin executing on each API request. + +Go plugins are the recommended plugin type and suitable for most use cases. +## Prerequisites + +* docker & docker-compose +* [A Tyk license](https://tyk.io/sign-up/#self) (if using Self-Managed Tyk, which will make the process easier via UI) +* Make +* OSX (Intel) -> Not a prerequisite, though these steps are tested on OSX Intel/ARM + +This tutorial will take between 15-20 minutes. diff --git a/tyk-docs/content/plugins/get-started-selfmanaged/run.md b/tyk-docs/content/plugins/get-started-selfmanaged/run.md new file mode 100644 index 0000000000..8912de7896 --- /dev/null +++ b/tyk-docs/content/plugins/get-started-selfmanaged/run.md @@ -0,0 +1,81 @@ +--- +date: 2017-03-24T15:45:13Z +title: Task 1 - Set up your environment +menu: + main: + parent: "Get Started with Custom Plugins" +weight: 10 +--- + +We have a getting started repo to help you set up your development environment. + +### 1. Clone the getting started repo + +Please clone the [getting started repo][0]. + + + +{{< tabs_start >}} +{{< tab_start "Self-Managed" >}} + +```bash +git clone https://github.com/TykTechnologies/custom-go-plugin + +``` + +{{< tab_end >}} +{{< tab_start "Open Source" >}} + +```bash +git clone https://github.com/TykTechnologies/custom-go-plugin +git checkout opensource +``` + + +{{< tab_end >}} +{{< tabs_end >}} + +### 2. Run the stack + +Navigate to the cloned repository and run the following command: + + +{{< tabs_start >}} +{{< tab_start "Self-Managed" >}} + +```shell +# Make a copy of the example .env file for the Tyk-Dashboard +cp tyk/confs/tyk_analytics.env.example tyk/confs/tyk_analytics.env +``` +Edit the file `tyk/confs/tyk_analytics.env` with your Tyk-Dashboard license key. + +Finally, run the `make` command: + +```bash +make +``` + +{{< tab_end >}} +{{< tab_start "Open Source" >}} + +run the `make` command: + +```bash +make +``` + +{{< tab_end >}} +{{< tabs_end >}} + + +This will take a few minutes to run as it compiles the plugin for the first time and downloads all the necessary Docker images. + +### What have we done? + +1. We've run a local Tyk stack. +2. We compiled the sample Go plugin and loaded it onto the Gateway's file system. + +Next, let's create an API definition and test our Go plugin in the next task. + + +[0]: https://github.com/TykTechnologies/custom-go-plugin \ No newline at end of file diff --git a/tyk-docs/content/plugins/get-started-selfmanaged/test.md b/tyk-docs/content/plugins/get-started-selfmanaged/test.md new file mode 100644 index 0000000000..fca5858f04 --- /dev/null +++ b/tyk-docs/content/plugins/get-started-selfmanaged/test.md @@ -0,0 +1,135 @@ +--- +date: 2017-03-24T15:45:13Z +title: Task 2 - Test Your Go Plugin +tags: ["Test Plugin", "Test Custom Plugin", "Tyk plugin", "Plugin", "Go plugin"] +menu: + main: + parent: "Get Started with Custom Plugins" +weight: 10 +--- + +{{< tabs_start >}} +{{< tab_start "Self-Managed" >}} + +### 1. Bootstrap the Dashboard + +Log on to the Tyk Dashboard on `http://localhost:3000` and follow the set up menu to bootstrap the Tyk organization. + + +### 2. Create an API + +Once you're logged on to the Tyk Dashboard, navigate to the "APIs" screen. + +Next, create a Tyk REST API with the below settings: + +- Leave the default target URL. +- Use whatever listen path, such as `httpbin` +- Turn off authentication for the API by setting the auth mode to "Keyless" at the bottom of the page `Core APIM settings`. + +### 3. Send an API Request to the API + +Using the Tyk Dashboard, we've created a keyless API Definition that's now been loaded on the Tyk Gateway. + +Let's send an API request to the API Gateway so it can reverse proxy to our API. + +```bash +### Use the listen path from step 2 +$ curl localhost:8080/httpbin/get +``` + +Yields the response: +``` +{ + "args": {}, + "headers": { + "Accept": "*/*", + "Host": "localhost:8000", + "User-Agent": "curl/7.79.1" + }, + "origin": "172.17.0.1", + "url": "http://localhost:8000/get" +} +``` + +We've sent an API request to the Tyk Gateway, it's reverse-proxied it to the Upstream API, `httpbin.org` to the `get` endpoint, which echo'd back the HTTP request to us. + +We can check the Analytics of this API request in the Dashboard, under the Analytics section. + +### 4. Add the Go Plugin + +If we inspect the sample Go plugin in `go/src/CustomGoPlugin.go`, we can see the `AddFooBarHeader` function which adds a Header "foo:bar" + +Here's how to add it to the API definition: + +Navigate back to the API we created, click on "VIEW RAW DEFINITION", and replace the default value for `custom_middleware` with the following: + +```json + "custom_middleware": { + "pre": [ + { + "name": "AddFooBarHeader", + "path": "/opt/tyk-gateway/middleware/CustomGoPlugin.so" + } + ], + "driver": "goplugin" + } +``` + +And hit update! + +If we tail the logs of the Docker container in the Gateway, we should see the following: + + +```logs +$ docker logs custom-go-plugin_tyk-gateway_1 + +... +time="Dec 19 12:03:34" level=info msg="--- Go custom plugin v4 init success! ---- " +... + +``` + + +### 5. Send the API request again + +```bash +$ curl localhost:8080/httpbin/get +``` + +Response: +```json +{ + "args": {}, + "headers": { + "Accept": "*/*", + "Host": "localhost:8000", + "User-Agent": "curl/7.79.1", + "Foo": "Bar" + }, + "origin": "172.17.0.1", + "url": "http://localhost:8000/get" +} +``` + +Awesome! Our Go plugin was executed, as evident in the echo response from our default API above which contains the newly added Header. + + +### Summary + +1. We've bootstrapped our Tyk organization. +2. We created our API and added the Tyk custom plugin to it. +3. We've sent an API request to the Gateway, and modified the API request in-flight using the Custom Go Plugin. + +We can make changes to the custom Go Plugin and run `make build` in order to test the new changes. + +{{< tab_end >}} +{{< tab_start "Open Source" >}} + +Coming soon. + +{{< tab_end >}} +{{< tabs_end >}} + +### Down + +Please run ```make down``` to bring down the stack. \ No newline at end of file diff --git a/tyk-docs/content/plugins/analytics-plugins.md b/tyk-docs/content/plugins/plugin-types/analytics-plugins.md similarity index 94% rename from tyk-docs/content/plugins/analytics-plugins.md rename to tyk-docs/content/plugins/plugin-types/analytics-plugins.md index a4bea6d84f..283579cdab 100755 --- a/tyk-docs/content/plugins/analytics-plugins.md +++ b/tyk-docs/content/plugins/plugin-types/analytics-plugins.md @@ -3,8 +3,10 @@ date: 2022-07-25 title: Analytics Plugins menu: main: - parent: "Custom Plugins" + parent: "Plugin Types" weight: 90 +aliases: + - /plugins/analytics-plugins --- Since Tyk 4.1.0 we have incorporated analytic plugins which enables editing or removal of all parts of analytics records and raw request and responses recorded by Tyk at the gateway level. This feature leverages existing Go plugin infrastructure. diff --git a/tyk-docs/content/plugins/auth-plugins.md b/tyk-docs/content/plugins/plugin-types/auth-plugins/auth-plugins.md similarity index 90% rename from tyk-docs/content/plugins/auth-plugins.md rename to tyk-docs/content/plugins/plugin-types/auth-plugins/auth-plugins.md index 4ff9a60e0b..82e4df2cee 100755 --- a/tyk-docs/content/plugins/auth-plugins.md +++ b/tyk-docs/content/plugins/plugin-types/auth-plugins/auth-plugins.md @@ -1,10 +1,14 @@ --- date: 2017-03-24T15:45:13Z title: Authentication Plugins +tags: ["Custom Auth Plugins", "Custom Auth", "Auth Plugins", "Authentication Plugins"] menu: main: - parent: "Custom Plugins" -weight: 9 + parent: "Plugin Types" +weight: 11 +aliases: + - "/plugins/auth-plugins" + --- If you have unique authentication requirements, you can write a custom authentication plugin. @@ -23,7 +27,7 @@ Tyk will try to be clever about what to cache, but we need to help it. There are ### The ID Extractor The ID Extractor is a caching mechanism that's used in combination with Tyk Plugins. It can be used specifically with plugins that implement custom authentication mechanisms. The ID Extractor works for all rich plugins: gRPC-based plugins, Python and Lua. -See [ID Extractor]({{< ref "plugins/auth-plugins/id-extractor" >}}) for more details. +See [ID Extractor]({{< ref "plugins/plugin-types/auth-plugins/id-extractor" >}}) for more details. ## Token Metadata Tyk creates an in-memory object to track the rate limit, quotas, and more for each session. diff --git a/tyk-docs/content/plugins/auth-plugins/id-extractor.md b/tyk-docs/content/plugins/plugin-types/auth-plugins/id-extractor.md similarity index 99% rename from tyk-docs/content/plugins/auth-plugins/id-extractor.md rename to tyk-docs/content/plugins/plugin-types/auth-plugins/id-extractor.md index b52e50c93d..cc29ceb7a5 100644 --- a/tyk-docs/content/plugins/auth-plugins/id-extractor.md +++ b/tyk-docs/content/plugins/plugin-types/auth-plugins/id-extractor.md @@ -8,6 +8,7 @@ weight: 3 aliases: - /customise-tyk/plugins/rich-plugins/id-extractor/ - /plugins/rich-plugins/id-extractor + - /plugins/auth-plugins/id-extractor --- ## Introduction diff --git a/tyk-docs/content/plugins/plugin-types/plugintypes.md b/tyk-docs/content/plugins/plugin-types/plugintypes.md new file mode 100644 index 0000000000..7ef1c112f7 --- /dev/null +++ b/tyk-docs/content/plugins/plugin-types/plugintypes.md @@ -0,0 +1,34 @@ +--- +title: "Plugin Types" +menu: + main: + parent: "Custom Plugins" +weight: 10 +--- + +Custom Plugins can be added and executed in several different phases of the API request lifecycle, and the correct phase to add it to depends on your use case. + +What's a phase? + +During an API request lifecycle, there are dozens of "middleware" that can be turned on and evaluated, such as rate limiting, quotas, analytics, authentication, and more. You can familiarize yourself with them [here][0]. + + +First, let's introduce the different types. + +- Request Plugin: executed before the reverse proxy to the upstream API. There are three sub-types, `pre`, `post`, and `post-auth` +- Authentication Plugin: Replaces Tyk's default auth system with a custom plugin you write +- Response Plugin: executed after the reverse proxy to the upstream API +- Analytics Plugin: executed before the API Analytics record is stored in Redis to be scraped by Tyk Pump + + +| Plugin Type | When Executed | Common Use Cases | +|--------------------------|--------------|--------------------|--------- +| Pre (Request) | The first thing to be executed, before any middleware. | IP Rate Limit plugins, API Request enrichment | +| Authentication | Replace Tyk's built in Authentication with your own business logic. | Interfacing with legacy Auth database | +| Post-Auth (Request) | Executed immediately after authentication middleware | Additional authentication | +| Post (Request) | The final middleware to be executed during the "request" phase | | +| Response | Executed immediately after the reverse proxy is returned from the upstream API to Tyk | | +| Analytics Plugin | The final middleware to be executed during the response phase | Obfuscating sensitive data | + + +[0]:http://localhost:1313/docs/nightly/concepts/middleware-execution-order/ \ No newline at end of file diff --git a/tyk-docs/content/plugins/request-plugins.md b/tyk-docs/content/plugins/plugin-types/request-plugins.md similarity index 89% rename from tyk-docs/content/plugins/request-plugins.md rename to tyk-docs/content/plugins/plugin-types/request-plugins.md index c111756947..468cfff1ba 100755 --- a/tyk-docs/content/plugins/request-plugins.md +++ b/tyk-docs/content/plugins/plugin-types/request-plugins.md @@ -3,11 +3,13 @@ date: 2017-03-24T15:45:13Z title: Request Plugins menu: main: - parent: "Custom Plugins" + parent: "Plugin Types" weight: 10 +aliases: + - /plugins/request-plugins --- -There are 4 different phases in the [request lifecycle]({{< ref "concepts/middleware-execution-order" >}}) you can inject custom plugins, including [Authentication plugins]({{< ref "plugins/auth-plugins" >}}). There are performance advantages to picking the correct phase, and of course that depends on your use case and what functionality you need. +There are 4 different phases in the [request lifecycle]({{< ref "concepts/middleware-execution-order" >}}) you can inject custom plugins, including [Authentication plugins]({{< ref "plugins/plugin-types/auth-plugins/auth-plugins" >}}). There are performance advantages to picking the correct phase, and of course that depends on your use case and what functionality you need. ### Hook Capabilities | Functionality | Pre | Auth | Post-Auth | Post | diff --git a/tyk-docs/content/plugins/response-plugins.md b/tyk-docs/content/plugins/plugin-types/response-plugins.md similarity index 96% rename from tyk-docs/content/plugins/response-plugins.md rename to tyk-docs/content/plugins/plugin-types/response-plugins.md index d24c94dcca..62d2ce646c 100755 --- a/tyk-docs/content/plugins/response-plugins.md +++ b/tyk-docs/content/plugins/plugin-types/response-plugins.md @@ -3,8 +3,10 @@ date: 2017-03-24T15:45:13Z title: Response Plugins menu: main: - parent: "Custom Plugins" + parent: "Plugin Types" weight: 20 +aliases: + - plugins/response-plugins --- Since Tyk 3.0 we have incorporated response hooks, this type of hook allows you to modify the response object returned by the upstream. The flow is follows: diff --git a/tyk-docs/content/plugins/supported-languages.md b/tyk-docs/content/plugins/supported-languages.md index 581a649f3b..2d5e3833df 100755 --- a/tyk-docs/content/plugins/supported-languages.md +++ b/tyk-docs/content/plugins/supported-languages.md @@ -4,7 +4,8 @@ title: Supported Languages menu: main: parent: "Custom Plugins" -weight: 8 +weight: 80 +url: "/plugins/supported-languages" --- There are 5 different places in the [API lifecycle]({{< ref "concepts/middleware-execution-order" >}}) you can inject custom plugins. There are performance advantages to picking the correct phase, and of course that depends on your use case and what functionality you need. @@ -77,6 +78,6 @@ Rich Plugins bring about the following improvements: [2] gRPC - Using gRPC, you can write plugins in Java, .NET, C++ / C#, PHP, [and all other supported languages](https://grpc.io/docs/languages/) -[3] ReturnOverrides - [Can be used to stop the request and return a response / error]({{< ref "plugins/request-plugins#return-overrides-returnoverrides" >}}) +[3] ReturnOverrides - [Can be used to stop the request and return a response / error]({{< ref "plugins/plugin-types/request-plugins#return-overrides-returnoverrides" >}}) [4] [How To Serve Middleware]({{< ref "plugins/how-to-serve-plugins" >}}) diff --git a/tyk-docs/content/plugins/supported-languages/golang.md b/tyk-docs/content/plugins/supported-languages/golang.md index e2eeb3b16c..3db4231083 100644 --- a/tyk-docs/content/plugins/supported-languages/golang.md +++ b/tyk-docs/content/plugins/supported-languages/golang.md @@ -8,6 +8,7 @@ weight: 0 aliases: - /plugins/golang-plugins/golang-plugins/ - /customise-tyk/plugins/golang-plugins/golang-plugins/ + - /plugins/supported-languages/golang/ --- This guide will help you to understand the idea behind Golang plugins in less than 5-10 minutes. diff --git a/tyk-docs/content/plugins/supported-languages/javascript-middleware.md b/tyk-docs/content/plugins/supported-languages/javascript-middleware.md index c63e137179..ee34790046 100755 --- a/tyk-docs/content/plugins/supported-languages/javascript-middleware.md +++ b/tyk-docs/content/plugins/supported-languages/javascript-middleware.md @@ -9,6 +9,7 @@ aliases: - /customise-tyk/plugins/javascript-middleware/ - /customise-tyk/plugins/javascript-middleware/middleware-execution-order/ - /plugins/javascript-middleware + - /plugins/supported-languages/javascript-middleware/ --- ## Customise JS Middleware Overview diff --git a/tyk-docs/content/plugins/supported-languages/rich-plugins.md b/tyk-docs/content/plugins/supported-languages/rich-plugins.md index 715d4f0640..6528747306 100755 --- a/tyk-docs/content/plugins/supported-languages/rich-plugins.md +++ b/tyk-docs/content/plugins/supported-languages/rich-plugins.md @@ -7,6 +7,7 @@ menu: weight: 1 aliases: - /plugins/rich-plugins + - /plugins/supported-languages/rich-plugins/ --- Rich plugins make it possible to write powerful middleware for Tyk. Tyk supports: diff --git a/tyk-docs/content/plugins/supported-languages/rich-plugins/rich-plugins-data-structures.md b/tyk-docs/content/plugins/supported-languages/rich-plugins/rich-plugins-data-structures.md index 30c60afd5d..17d522e1f7 100644 --- a/tyk-docs/content/plugins/supported-languages/rich-plugins/rich-plugins-data-structures.md +++ b/tyk-docs/content/plugins/supported-languages/rich-plugins/rich-plugins-data-structures.md @@ -260,7 +260,7 @@ Tags are embedded into analytics data when the request completes. If a policy ha As of v2.1, an Alias offers a way to identify a token in a more human-readable manner, add an Alias to a token in order to have the data transferred into Analytics later on so you can track both hashed and un-hashed tokens to a meaningful identifier that doesn't expose the security of the underlying token. `id_extractor_deadline` -See [Auth Plugins]({{< ref "plugins/auth-plugins" >}}) for additional information. +See [Auth Plugins]({{< ref "plugins/plugin-types/auth-plugins/auth-plugins" >}}) for additional information. `session_lifetime` Overrides the global session lifetime, see [Physical Token Expiry]({{< ref "basic-config-and-security/security/authentication-authorization/physical-key-expiry" >}}) for additional information. diff --git a/tyk-docs/content/plugins/supported-languages/rich-plugins/rich-plugins-work.md b/tyk-docs/content/plugins/supported-languages/rich-plugins/rich-plugins-work.md index fde664e079..4a3a099780 100755 --- a/tyk-docs/content/plugins/supported-languages/rich-plugins/rich-plugins-work.md +++ b/tyk-docs/content/plugins/supported-languages/rich-plugins/rich-plugins-work.md @@ -13,7 +13,7 @@ aliases: The ID Extractor is a caching mechanism that's used in combination with Tyk Plugins. It can be used specifically with plugins that implement custom authentication mechanisms. The ID Extractor works for all rich plugins: gRPC-based plugins, Python and Lua. -See [ID Extractor]({{< ref "plugins/auth-plugins/id-extractor" >}}) for more details. +See [ID Extractor]({{< ref "plugins/plugin-types/auth-plugins/id-extractor" >}}) for more details. ### Interoperability