This solution is for NGINX Plus prior to R23. Since NGINX Plus R23, gRPC health checks can be enabled with
health_check type=grpc;
https://www.nginx.com/blog/nginx-plus-r23-released/#grpc-health-checks
This solution is for NGINX Plus prior to R23. Since NGINX Plus R23, gRPC health checks can be enabled with
health_check type=grpc;
https://www.nginx.com/blog/nginx-plus-r23-released/#grpc-health-checks
#!/bin/sh | |
# | |
# compile_module.sh (c) NGINX, Inc. [v0.6 28-Aug-2018] Liam Crilly <liam.crilly@nginx.com> | |
# | |
# This script supports Ubuntu, RedHat and CentOS package managers | |
# Installs the minimum necessary prerequisite packages to build 3rd party modules for NGINX Plus | |
# Obtains source for module and NGINX OSS, compiles the module .so and cleans up. | |
# Inspects module configuration and attempts to rewrite for dynamic build if necessary. | |
# | |
# CHANGELOG |
This configuration can be used to log all of the request headers presented by a client. We use the JavaScript (njs) module to iterate over each header, returning a list of JSON key-value pairs which are then included in a JSON log format.
js_include functions.js;
js_set $headers_json headers_to_json;
log_format json escape=none '{"timestamp":"$time_iso8601",'
This configuration enables NGINX to validate an authentication token against an authorization server by using OAuth 2.0 Token Introspection (RFC 7662). This solution uses the auth_request module and the NGINX JavaScript module to require authentication and perform the token introspection request.
By default, the client's authentication token is expected as a bearer token supplied in the Authorization
header. If supplied elsewhere in the HTTP request, the $access_token
variable must be configured to specify where to obtain the token.
Token introspection requests are authenticated. By default, the $oauth_client_id
and $oauth_client_secret
variables are used to perform HTTP Basic authentication with the Authorization Server. If only the $oauth_client_secret
variable is specified then that value is used
NGINX is the world’s number one API gateway, delivering the vast majority of today’s API traffic, deployed as standalone gateways or embedded in API management products. This workshop is about deploying NGINX as a lightweight API gateway in a way that supports long-term maintenance and can be automated with common DevOps tooling.
In this hands-on workshop, you will configure NGINX to perform the common API gateway functions of request routing, rate limiting, and authentication for multiple APIs. We will also touch on advanced use cases such as HTTP method enforcement, and JSON validation.
Previous experience of NGINX is valuable, but not essential. Technical requirements:
#!/usr/bin/env bash | |
# get_server.sh (c) NGINX, Inc. [v0.3 10-Jul-2019] Liam Crilly <liam.crilly@nginx.com> | |
if [ $# -lt 1 ]; then | |
echo "USAGE: ${0##*/} [URI ...]" | |
exit 1 | |
fi | |
for site in "$@"; do | |
echo -n "$site " |
js_import json_log.js; | |
js_set $json_debug_log json_log.debugLog; | |
log_format access_debug escape=none $json_debug_log; | |
access_log /var/log/nginx/access_debug.log access_debug if=$is_error; | |
map $status $is_error { | |
# List of response codes that warrant a detailed log file | |
400 1; # Bad request, including expired client cert | |
495 1; # Client cert error |
js_import conf.d/echo.js; | |
map $request_method $return_code { | |
"POST" 201; | |
"DELETE" 204; | |
default 200; | |
} | |
keyval_zone zone=kv:32k; | |
keyval '1' $has_keyval zone=kv; |
This is a complete demo of 2 different cookie security techniques:
Requires NGINX Plus with JavaScript module (njs 0.5.1+)