Pre OSS commit

Author: nginx

content/includes/nap-waf/config/v5/apreload.md renamed to content/includes/nap-waf/concept/apreload.md

@@ -1,5 +1,5 @@
 ---
-docs: ""
+docs: DOCS-000
 ---
 
 apreload is a tool that can update that can update the NGINX App Protect WAF configuration without having to reload NGINX if only the App Protect configuration is changed and the `nginx.conf` file remains unchanged. apreload does not affect the existing NGINX reload process and it functions in the same manner as before.

content/includes/nap-waf/config/v5/attack-signatures-overview-v5.md renamed to content/includes/nap-waf/concept/attack-signatures.md

@@ -1,5 +1,5 @@
 ---
-docs: "DOCS-1621"
+docs: DOCS-000
 ---
 
 Attack signatures are rules or patterns that identify attack sequences or classes of attacks on a web application and its components. You can apply attack signatures to both requests and responses. App Protect includes predefined attack signatures to protect your application against all attack types identified by the system.

content/includes/nap-waf/config/v5/basic-config-and-default-policy-v5.md renamed to content/includes/nap-waf/concept/basic-config-default-policy.md

@@ -1,5 +1,5 @@
 ---
-docs: "DOCS-1633"
+docs: DOCS-000
 ---
 
 The base template is the common starting point to any policy you write. The default policy just reflects that template without any further modifications, thus we use the terms **base template** and **default policy** interchangeably. The default policy appears as follows

content/includes/nap-waf/config/v4/external-references-v4.md renamed to content/includes/nap-waf/concept/external-references.md

@@ -1,12 +1,11 @@
 ---
-docs: "DOCS-1531"
+docs: DOCS-000
 ---
 
 External references in policy are defined as any code blocks that can be used as part of the policy without being explicitly pasted within the policy file. This means that you can have a set of pre-defined configurations for parts of the policy, and you can incorporate them as part of the policy by simply referencing them. This would save a lot of overhead having to concentrate everything into a single policy file.
 
 A perfect use case for external references is when you wish to build a dynamic policy that depends on moving parts. You can have code create and populate specific files with the configuration relevant to your policy, and then compile the policy to include the latest version of these files, ensuring that your policy is always up to date when it comes to a constantly changing environment.
 
-
 **Note**: Any update of a single file referenced in the policy will not trigger a policy compilation. This action needs to be done actively by reloading the NGINX configuration.
 
 To use the external references capability, in the policy file the direct property is replaced by "xxxReference" property, where xxx defines the replacement text for the property changed to singular (if originally plural) and notation converted from snake case to camelCase. For example, `modifications` section is replaced by `modificationsReference` and `data-guard` is replaced by `dataGuardReference`.

content/includes/nap-waf/config/v4/global-directives-v4.md renamed to content/includes/nap-waf/concept/global-directives.md

@@ -1,5 +1,5 @@
 ---
-docs: "DOCS-1525"
+docs: DOCS-000
 ---
 
 Global configuration consists of a series of `nginx.conf` directives at the `http` context controlling aspects that are not specific to a specific application.
@@ -8,7 +8,7 @@ When applied to a cluster, all cluster members will get the same globals as expe
 
 {{< note >}} Whether an incoming request is inspected by NGINX App Protect WAF may be determined by the URL in the request. This happens if you configure `app_protect_enable` and `app_protect_policy_file` directives in the `location` scope. In the case where the URL itself has violations such as *bad unescape* or *illegal metacharacter* then the request might be assigned to a location in which NGINX App Protect WAF is disabled or has a relaxed policy that does not detect these violations. Such malicious requests will be allowed without inspection. In order to avoid this, it is recommended to have a basic policy enabled at the `http` scope or at least at the `server` scope to process malicious requests in a more complete manner.{{< /note >}}
 
-{{<bootstrap-table "table table-striped table-bordered table-sm table-responsive">}}
+{{< bootstrap-table "table table-striped table-bordered table-sm table-responsive" >}}
 |Directive Name | Syntax | Description | Default |
 | ---| ---| ---| --- |
 |app_protect_physical_memory_util_thresholds | app_protect_physical_memory_util_thresholds high=<number_0-100> low=<number_0-100> | Sets the physical memory utilization thresholds for entering (high) and exiting (low) failure mode. When the high threshold is exceeded the system enters failure mode until memory drops below the low threshold. Setting the value of 100 disables this feature. | high=low=100 (disabled) |
@@ -19,4 +19,4 @@ When applied to a cluster, all cluster members will get the same globals as expe
 |app_protect_request_buffer_overflow_action | app_protect_request_buffer_overflow_action pass &#124; drop | Determines how to handle requests in case the NGINX request buffer is full and requests cannot be buffered anymore. There are two values:<ul><li>**pass**: Pass the request without App Protect Enforcer inspection, a.k.a. "fail-open".</li><li>**drop**: Drop the request by resetting connection. No response page is returned, a.k.a. "fail-close".</li></ul> | pass |
 |app_protect_user_defined_signatures | app_protect_user_defined_signatures <path> | Imports the user-defined tagged signature file with the respective tag name from the provided path. Multiple instances of this directive are supported. In order to import multiple signatures files, each file must have a different tag. | N/A |
 |app_protect_reconnect_period_seconds| app_protect_reconnect_period_seconds <value> <br> **Value type**: number with decimal fraction <br> **Value Range**:  0-60. 0 is illegal | Determines the period of time between reconnect retries of the module to the web application firewall (WAF) engine. The time unit is seconds.| 5 |
-{{</bootstrap-table>}}
+{{< /bootstrap-table >}}

content/includes/nap-waf/config/v5/graphql-profile-v5.md renamed to content/includes/nap-waf/concept/graphql-profile.md

@@ -1,5 +1,5 @@
 ---
-docs: "DOCS-1630"
+docs: DOCS-000
 ---
 
 The GraphQL Profile defines the GraphQL properties that are enforced by the security policy.
@@ -38,6 +38,4 @@ In the GraphQL profile example below, we changed the "defenseAttributes" to cust
             }
          }
      ]
-```
-
-{{< note >}}For GraphQL profile default values and GraphQL violations reference, see NGINX App Protect WAF [Declarative Policy guide.]({{< relref "/nap-waf/v5/declarative-policy/policy.md" >}}) {{< /note >}}
+```

content/includes/nap-waf/config/v5/grpc-logging-v5.md renamed to content/includes/nap-waf/concept/grpc-logging.md

@@ -1,5 +1,5 @@
 ---
-docs: "DOCS-1625"
+docs: DOCS-000
 ---
 
 Security log for gRPC requests has unique fields: `uri`, `grpc_method`, and `grpc_service`. Also, since the content of gRPC requests is binary (Protocol Buffers), it is better transferred in Base64 encoding. Hence, it is recommended to use the `headers` and `request_body_base64` fields instead of the `request` field. A new predefined log format called `grpc` should be used in all gRPC locations that also use policies with gRPC Content Profiles.
@@ -20,4 +20,4 @@ server {
         grpc_pass grpcs://grpc_backend;
     }
 }
-```
+```

content/includes/nap-waf/config/v5/strict-policy-v5.md renamed to content/includes/nap-waf/concept/strict-policy.md

@@ -1,7 +1,3 @@
----
-docs: "DOCS-1624"
----
-
 The Strict Policy is recommended as a starting point for applications requiring a higher level of security. Just like all other policies it is based on the base template, so it detects and blocks everything the default policy does.
 To obtain the Strict Policy, execute the following command: