Import

What Is Import?

Import restores the JSON file downloaded with Export to the selected vService. The scope is not a single card or a single threshold but the whole Bot/DDoS configuration of the vService: the protections, the whitelists, the notification settings and the learning settings come together with the file. The Import button, together with Export, is located at the bottom right of the Bot/DDoS Protection Mode strip and is displayed only on the users that have edit permission; on the users without permission these two buttons are not created at all.

The import is a full replacement

The settings in the file are not merged with the existing configuration; the Bot/DDoS configuration of the vService that is in force is entirely replaced by the one in the file. The operation cannot be undone and takes effect right after the confirmation. For this reason it is recommended that the existing configuration be backed up with Export before the import.

The Import Steps

1. The Import button at the bottom right of the strip is clicked. The button opens a hidden file input; in the picker the .json filter is applied by default. This filter only makes the selection easier: no extension check is made on the server side, the file is validated only by its content being parsed as JSON.

2. After the file is selected, the confirmation window opens. The window states, together with the name of the target, that the operation is a full replacement and that it will be written to the user log with a change summary:

   The ENTIRE Bot/DDoS protection configuration of vService "<vService name>" will be REPLACED with the selected file — protections, whitelists, notification and learning settings included. The operation is written to the user logs with a change summary. Continue?

3. The operation is confirmed with the Yes button; if No is selected, no request is sent to the server and no change is made.

4. After the confirmation, the file is uploaded to the server with a multipart/form-data request. Both buttons become passive at the moment the file is selected; the confirmation window also opens at this time. The icon of the working button turns into a spinning symbol and the buttons become enabled again a short time after the operation ends.

5. When the operation ends, the file input is reset; in this way the same file can be selected again if necessary.

The Import Button

The import is applied over the record line through which every edit made manually passes: the new configuration is written to the database, and the regeneration of the Load Balancer configuration and its application to the system run in the background right after this. There is no separate deployment (deploy) step; on a successful import no notification is shown either, and the cards on the strip are updated according to the file content. If there is a system synchronization going on at that moment on the server, the request is rejected; if there is another simultaneous Load Balancer write, the operation is queued.

Validation and Errors

• If the request does not carry a file, the operation is rejected before it even starts.
• If the target vService does not have a registered Bot/DDoS configuration, the import is stopped. The record is created with the default values right after the protection is enabled, while the configuration is being applied; a file cannot be loaded to a vService whose protection has never been enabled.
• If the file cannot be parsed as JSON or if the parsed root element is not an object (for example if it is an array or plain text), the operation is rejected with the "Corrupted threat protection file" error.
• In all of these errors the existing configuration stays unchanged; the record is written only after all the validations are passed.
• The temporary file uploaded is deleted from the server whether the operation ends successfully or with an error.

The unrecognized keys are dropped silently

The keys in the file are filtered according to the key set of the device's own Bot/DDoS schema: every key that has no equivalent in the schema is discarded and only the recognized keys are applied. Which keys have been dropped is not reported to the user; the response returns only success. For this reason a file taken from a device of a different version can be applied incompletely and the operation still appears successful. In the extreme case, a valid JSON file that contains no recognized key (for example {}) is also accepted and returns the whole protection configuration of the vService to the default behavior. After a transfer between versions, the configuration must be verified visually over the cards.

If the operation takes long, no result may appear on the screen

For the import request a 10-second timeout is applied on the client side (in the export this period is 60 seconds). If the period is exceeded, neither a success nor an error notification is shown; the button only returns to its old state. This does not mean that the operation has failed: the server may have completed the request. In such a case the result must be verified from the cards on the strip and from the user log.

The file is bound to the target vService

The file does not carry the information of which vService it was taken from; the record identity is rewritten according to the target vService during the import. For this reason a file taken from one vService can be loaded to another vService that has a Bot/DDoS configuration. The carrying of the configuration between vServices or devices is done in this way.

The scope exception

The record identity and the protection priority fields (ddosProtectionPriority, botPriority, ipRepPriority) are not carried with the file: they do not enter the export output at all and, even if they have been added manually in the file, they are ignored in the import. Since the import changes the whole of the record, if these fields have a value in the target record, they drop from the record after the import and the order of the protection columns returns to the default order.

The import requires Load Balancer write permission

The Import button is bound to the same condition as Export: it is displayed only on the users that have edit permission in the Load Balancer area. On the server side too, the request is evaluated as a Load Balancer write call and write permission in the Load Balancer area is looked for; the two conditions overlap. With read-only permission, on the other hand, the buttons are not located there at all.

The user log record

The import is written to the user log with the record Threat protection configuration of "<vService name>" is replaced from an imported file. Since the record carries the configuration before and after the operation together, it produces a change summary; which settings have turned into what can be followed field by field over the log record.

Operational Best Practices

• The existing configuration should be backed up before the import. The import cannot be undone; the file taken with Export beforehand is the only way of return.
• Only the Export output should be used. The file content is validated only at a minimum level and the unrecognized keys are discarded silently; a file that has been edited manually or produced from a different source can lead to a protection different from the expected one coming into force.
• The target vService should be verified before the import. Since the file does not carry the source vService information, loading to the wrong vService can be done without being noticed; since the operation is applied right after the confirmation and cannot be undone, the name of the target must be confirmed by reading it in the confirmation window.