config.handler.yml Maven / Gradle / Ivy
# Handler middleware chain configuration
---
enabled: true
# Configuration for the LightHttpHandler. The handler is the base class for all middleware, server and health handlers
# set the Status Object in the AUDIT_INFO, for auditing purposes
# default, if not set:false
auditOnError: ${handler.auditOnError:false}
# set the StackTrace in the AUDIT_INFO, for auditing purposes
# default, if not set:false
auditStackTrace: ${handler.auditStackTrace:false}
# Base Path of the API endpoints
basePath: ${handler.basePath:/v1}
#------------------------------------------------------------------------------
# Support individual handler chains for each separate endpoint. It allows framework
# handlers like health check, server info to bypass majority of the middleware handlers
# and allows mixing multiple frameworks like OpenAPI and GraphQL in the same instance.
#
# handlers -- list of handlers to be used across chains in this microservice
# including the routing handlers for ALL endpoints
# -- format: fully qualified handler class name@optional:given name
# chains -- allows forming of [1..N] chains, which could be wholly or
# used to form handler chains for each endpoint
# ex.: default chain below, reused partially across multiple endpoints
# paths -- list all the paths to be used for routing within the microservice
# ---- path: the URI for the endpoint (ex.: path: '/v1/pets')
# ---- method: the operation in use (ex.: 'post')
# ---- exec: handlers to be executed -- this element forms the list and
# the order of execution for the handlers
#
# IMPORTANT NOTES:
# - to avoid executing a handler, it has to be removed/commented out in the chain
# or change the enabled:boolean to false for a middleware handler configuration.
# - all handlers, routing handler included, are to be listed in the execution chain
# - for consistency, give a name to each handler; it is easier to refer to a name
# vs a fully qualified class name and is more elegant
# - you can list in chains the fully qualified handler class names, and avoid using the
# handlers element altogether
#------------------------------------------------------------------------------
handlers:
# Light-framework cross-cutting concerns implemented in the microservice
- com.networknt.exception.ExceptionHandler@exception
- com.networknt.metrics.MetricsHandler@metrics
- com.networknt.traceability.TraceabilityHandler@traceability
- com.networknt.correlation.CorrelationHandler@correlation
# Cors handler to handler post/put pre-flight. It is not used in the sidecar but only in the router.
- com.networknt.cors.CorsHttpHandler@cors
# - com.networknt.openapi.OpenApiHandler@specification
# - com.networknt.openapi.JwtVerifyHandler@security
# - com.networknt.body.BodyHandler@body
# - com.networknt.audit.AuditHandler@audit
# - com.networknt.sanitizer.SanitizerHandler@sanitizer
# - com.networknt.openapi.ValidatorHandler@validator
# Header middleware to manipulate request and/or response headers before or after downstream server
- com.networknt.header.HeaderHandler@header
# Rate limit middleware to prevent DDoS attacks externally or throttle requests internally
- com.networknt.limit.LimitHandler@limit
# Direct requests to named services based on the request path
#- com.networknt.router.middleware.ServiceDictHandler@path
#- com.networknt.router.middleware.PathServiceHandler@path
#- com.networknt.router.middleware.PathPrefixServiceHandler@prefix
- com.networknt.router.RouterHandler@router
# - com.networknt.resource.VirtualHostHandler@virtual
- com.networknt.config.reload.handler.ModuleRegistryGetHandler@modules
- com.networknt.config.reload.handler.ConfigReloadHandler@configReload
# Customer business domain specific cross-cutting concerns handlers
# - com.example.validator.CustomizedValidator@custvalidator
# Framework endpoint handlers
- com.networknt.health.HealthGetHandler@health
- com.networknt.info.ServerInfoGetHandler@info
- com.networknt.logging.handler.LoggerGetHandler@getLogger
- com.networknt.logging.handler.LoggerPostHandler@postLogger
- com.networknt.logging.handler.LoggerGetLogContentsHandler@getLogContents
# - com.networknt.metrics.prometheus.PrometheusGetHandler@getprometheus
- com.networknt.auth.StatelessAuthHandler@stateless
chains:
default:
- exception
- metrics
- traceability
- correlation
- cors
- stateless
- header
#- path
#- prefix
- router
#- specification
#- security
#- body
#- audit
#- sanitizer
#- validator
admin:
- exception
- correlation
- specification
- security
- body
- validator
paths:
- path: '/*'
method: 'GET'
exec:
- default
- path: '/*'
method: 'POST'
exec:
- default
- path: '/*'
method: 'PUT'
exec:
- default
- path: '/*'
method: 'DELETE'
exec:
- default
- path: '/*'
method: 'PATCH'
exec:
- default
- path: '/*'
method: 'OPTIONS'
exec:
- default
# In most case, the /server/info endpoint shouldn't be exposed. If it is, then it must be protected by OAuth 2.0
- path: '/server/info'
method: 'get'
exec:
- admin
- info
# the health endpoint for the proxy itself without security, this for both Kubernetes liveness and readiness.
- path: '/health'
method: 'get'
exec:
- exception
- health
# the health check endpoint called from control plane with security and it will invoke backend optionally.
- path: '/health/${server.serviceId}'
method: 'get'
exec:
- admin
- health
- path: '/logger'
method: 'get'
exec:
- admin
- getLogger
- path: '/logger'
method: 'post'
exec:
- admin
- postLogger
- path: '/logger/content'
method: 'GET'
exec:
- admin
- getLogContents
- path: '/modules'
method: 'get'
exec:
- modules
- path: '/modules'
method: 'post'
exec:
- body
- configReload