What happens to existing rules when I Import (full replacement)?
Short answer
Import is a replacement, not an addition: all the page types of the open host group (including Any Paths) are removed and the rules in the file are put in their place. If there is no Any paths in the file, it is set up automatically at the end of the operation with its default configuration and the default header rules. The only confirmation is the Are you sure? question; no success notification is shown, and the list and the N page types number change. The only way back is an Export file taken beforehand. If the file cannot be read as JSON (Corrupted WAF rules file) or a pattern in the file cannot be compiled (Invalid WAF pattern), the whole import is rejected and the existing set does not change (validation and errors). Import (OpenAPI) is different: it merges and replaces only the rules of the paths in the document. The change is applied without a separate deployment step.
How Does It Work?
- On the Page types tab, Import is clicked, the file is selected and Yes is clicked in the Are you sure? question (the import steps).
- The file is read as JSON and all the patterns in it go through a compilation check; if there is an error, the operation stops and the existing set does not change.
- The rule list of the open host group is replaced with the list in the file; if Any paths is missing, it is added with its default, and the rules are sorted.
- The new set is applied without a separate deployment step; in a cluster setup, it is also sent to the peer device with the default auto-sync, and if Manual Sync Mode is on, it is sent manually with Synchronize.
Comparison
| Import (JSON) | Import (OpenAPI) | |
|---|---|---|
| Existing rules | All are removed | The ones not in the document are preserved |
| A rule with the same path | The one in the file comes | The rule produced from the document replaces the existing one |
| Any paths | Replaced with the one in the file; if it is not in the file, set up with the default | A third-party document does not touch it; TR7's own output replaces it with the one in the document |
| File format | Export output (JSON) | OpenAPI 3 or Swagger 2.0 (JSON, YAML) |
| Error | The file is rejected entirely, the set does not change | An unreadable document or a pattern that cannot be compiled rejects the operation entirely; paths that cannot be converted and value patterns that are not suitable for the signature engine are skipped and listed as warnings in the result notification |
| Confirmation | Are you sure? | Are you sure? |
| Result notification | None | OpenAPI import: N path applied (with warnings) |
- For a way back, the Export file of the open group is taken before the import (Can I export a host group's rule set as JSON and move it to another environment; which settings are not included in the file?).
- The import record appears on the User Logs screen as N WAF rules are imported from file for group@vService.
- Import changes only the rule list; the name, mode and host patterns of the host group and the WAF settings of the vService do not change.
- OpenAPI behavior: Can I generate rules automatically from my OpenAPI / Swagger file?
Common Misconceptions
- "Import adds on top of the existing rules." Import is a full replacement; the rules that are not in the file are deleted.
- "Even if there is a partial error, the valid rules are loaded." A single pattern that cannot be compiled causes the whole file to be rejected.
- "The file is loaded to whichever group it belongs to." The file does not carry group information; Import replaces the set of the group from whose Page types tab it is done.
How it is done in the documentation
