Skip to content
Kong Logo | Kong Docs Logo
search
  • We're Hiring!
  • Docs
    • Kong Gateway
    • Kong Konnect
    • Kong Mesh
    • Plugin Hub
    • decK
    • Kubernetes Ingress Controller
    • Insomnia
    • Kuma

    • Docs contribution guidelines
  • Plugin Hub
  • Support
  • Community
  • Kong Academy
Early Access
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Plugin Hub
  • decK
  • Kubernetes Ingress Controller
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 3.1.x (latest)
  • 3.0.x
  • 2.8.x
  • 2.7.x
  • 2.6.x
  • Older Enterprise versions (2.1-2.5)
  • Older OSS versions (2.1-2.5)
  • Archive (pre-2.1)
    • Version Support Policy
    • Compatibility
    • Changelog
    • Kubernetes
    • Helm
    • OpenShift with Helm
    • Docker
    • Amazon Linux
    • CentOS
    • macOS
    • Debian
    • RHEL
    • Ubuntu
    • Migrating from OSS to EE
    • Upgrade Kong Gateway
    • Upgrade Kong Gateway OSS
      • Configuring a Service
      • Configuring a gRPC Service
      • Enabling Plugins
      • Adding Consumers
      • Prepare to Administer
      • Expose your Services
      • Protect your Services
      • Improve Performance
      • Secure Services
      • Set Up Intelligent Load Balancing
      • Manage Administrative Teams
      • Publish, Locate, and Consume Services
    • Running Kong as a Non-Root User
    • Resource Sizing Guidelines
      • Deploy Kong Gateway in Hybrid Mode
    • Kubernetes Deployment Options
    • Control Kong Gateway through systemd
    • Performance Testing Framework
    • DNS Considerations
    • Default Ports
      • Access Your License
      • Deploy Your License
      • Monitor License Usage
      • Start Kong Gateway Securely
      • Keyring and Data Encryption
      • Kong Security Update Process
      • Authentication Reference
        • OpenID Connect with Curity
        • OpenID Connect with Azure AD
        • OpenID Connect with Google
        • OpenID Connect with Okta
        • OpenID Connect with Auth0
        • OpenID Connect with Cognito
        • OpenID Connect Plugin Reference
      • Allowing Multiple Authentication Methods
        • Create a Super Admin
        • Configure Networking
        • Configure Kong Manager to Send Email
        • Reset Passwords and RBAC Tokens
        • Configure Workspaces
        • Basic Auth
        • LDAP
        • OIDC
        • Sessions
        • Add a Role
        • Add a User
        • Add an Admin
      • Mapping LDAP Service Directory Groups to Kong Roles
      • Enable the Dev Portal
      • Structure and File Types
      • Portal API Documentation
      • Working with Templates
      • Using the Editor
          • Basic Auth
          • Key Auth
          • OIDC
          • Sessions
          • Adding Custom Registration Fields
        • SMTP
        • Workspaces
        • Manage Developers
        • Developer Roles and Content Permissions
          • Authorization Provider Strategy
          • Enable Application Registration
          • Enable Key Authentication for Application Registration
          • External OAuth2 Support
          • Set up Okta and Kong for external OAuth
          • Set Up Azure AD and Kong for External Authentication
          • Manage Applications
        • Easy Theme Editing
        • Migrating Templates Between Workspaces
        • Markdown Rendering Module
        • Customizing Portal Emails
        • Adding and Using JavaScript Assets
        • Single Page App in Dev Portal
        • Alternate OpenAPI Renderer
      • Helpers CLI
    • Configure gRPC Plugins
    • GraphQL Quickstart
    • Logging Reference
    • Network and Firewall
      • Metrics
      • Reports
      • Vitals with InfluxDB
      • Vitals with Prometheus
      • Estimate Vitals Storage in PostgreSQL
    • Prometheus plugin
    • Zipkin plugin
      • DB-less Mode
      • Declarative Configuration
      • Supported Content Types
      • Information Routes
      • Health Routes
      • Tags
      • Service Object
      • Route Object
      • Consumer Object
      • Plugin Object
      • Certificate Object
      • CA Certificate Object
      • SNI Object
      • Upstream Object
      • Target Object
        • Licenses Reference
        • Licenses Examples
        • Workspaces Reference
        • Workspace Examples
        • RBAC Reference
        • RBAC Examples
        • API Reference
        • Examples
        • API Reference
        • Examples
        • Event Hooks Reference
        • Examples
      • Audit Logging
      • Keyring and Data Encryption
      • Securing the Admin API
    • DB-less and Declarative Configuration
    • Configuration Reference
    • CLI Reference
    • Load Balancing Reference
    • Proxy Reference
    • Rate Limiting Library
    • Health Checks and Circuit Breakers Reference
    • Clustering Reference
      • kong.client
      • kong.client.tls
      • kong.cluster
      • kong.ctx
      • kong.ip
      • kong.log
      • kong.nginx
      • kong.node
      • kong.request
      • kong.response
      • kong.router
      • kong.service
      • kong.service.request
      • kong.service.response
      • kong.table
      • Introduction
      • File structure
      • Implementing custom logic
      • Plugin configuration
      • Accessing the datastore
      • Storing custom entities
      • Caching custom entities
      • Extending the Admin API
      • Writing tests
      • (un)Installing your plugin
    • Plugins in Other Languages
    • File Permissions Reference

github-edit-pageEdit this page

report-issueReport an issue

enterprise-switcher-iconSwitch to OSS

On this page
  • kong.ctx
    • kong.ctx.shared
    • kong.ctx.plugin
Kong Gateway
2.7.x
  • Home
  • Kong Gateway
  • PDK
  • kong.ctx
You are browsing documentation for an outdated version. See the latest documentation here.

kong.ctx

kong.ctx

Current request context data

kong.ctx.shared

A table that has the lifetime of the current request and is shared between all plugins. It can be used to share data between several plugins in a given request.

Since only relevant in the context of a request, this table cannot be accessed from the top-level chunk of Lua modules. Instead, it can only be accessed in request phases, which are represented by the rewrite, access, header_filter, response, body_filter, log, and preread phases of the plugin interfaces. Accessing this table in those functions (and their callees) is fine.

Values inserted in this table by a plugin will be visible by all other plugins. One must use caution when interacting with its values, as a naming conflict could result in the overwrite of data.

Phases

  • rewrite, access, header_filter, response, body_filter, log, preread

Usage

-- Two plugins A and B, and if plugin A has a higher priority than B's
-- (it executes before B):

-- plugin A handler.lua
function plugin_a_handler:access(conf)
  kong.ctx.shared.foo = "hello world"

  kong.ctx.shared.tab = {
    bar = "baz"
  }
end

-- plugin B handler.lua
function plugin_b_handler:access(conf)
  kong.log(kong.ctx.shared.foo) -- "hello world"
  kong.log(kong.ctx.shared.tab.bar) -- "baz"
end

Back to top

kong.ctx.plugin

A table that has the lifetime of the current request - Unlike kong.ctx.shared, this table is not shared between plugins. Instead, it is only visible for the current plugin instance. That is, if several instances of the rate-limiting plugin are configured (e.g. on different Services), each instance has its own table, for every request.

Because of its namespaced nature, this table is safer for a plugin to use than kong.ctx.shared since it avoids potential naming conflicts, which could lead to several plugins unknowingly overwriting each other’s data.

Since only relevant in the context of a request, this table cannot be accessed from the top-level chunk of Lua modules. Instead, it can only be accessed in request phases, which are represented by the rewrite, access, header_filter, body_filter, log, and preread phases of the plugin interfaces. Accessing this table in those functions (and their callees) is fine.

Values inserted in this table by a plugin will be visible in successful phases of this plugin’s instance only. For example, if a plugin wants to save some value for post-processing during the log phase:

Phases

  • rewrite, access, header_filter, response, body_filter, log, preread

Usage

-- plugin handler.lua

function plugin_handler:access(conf)
  kong.ctx.plugin.val_1 = "hello"
  kong.ctx.plugin.val_2 = "world"
end

function plugin_handler:log(conf)
  local value = kong.ctx.plugin.val_1 .. " " .. kong.ctx.plugin.val_2

  kong.log(value) -- "hello world"
end

Back to top

Thank you for your feedback.
Was this page useful?
  • Kong
    THE CLOUD CONNECTIVITY COMPANY

    Kong powers reliable digital connections across APIs, hybrid and multi-cloud environments.

    • Company
    • Customers
    • Events
    • Investors
    • Careers Hiring!
    • Partners
    • Press
    • Contact
  • Products
    • Kong Konnect
    • Kong Gateway
    • Kong Mesh
    • Get Started
    • Pricing
  • Resources
    • eBooks
    • Webinars
    • Briefs
    • Blog
    • API Gateway
    • Microservices
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Solutions
    • Decentralize
    • Secure & Govern
    • Create a Dev Platform
    • API Gateway
    • Kubernetes
    • Service Mesh
Star
  • Terms•Privacy
© Kong Inc. 2023