When Changes Are Saved and Become Active

Changes that become active immediately

You can only carry out these changes if you belong to the “zeusafm Administrator”user group or to another group that has the appropriate user rights.

Changes that affect your system as a whole become active automatically and immediately. You don’t have to commit them, and you don’t need to activate them manually. Therefore, these changes don’t appear as changes on the status display and in the change log.

Changes that become active immediately include the following in particular:

• adding, deleting, and renaming applications (see Application Control)

• assigning an administrator to an application (see Editing Applications, Viewing, adding and removing administrators)

• adding, deleting, and editing users (see User Management)

• changes to the Global Configuration

• blocking / unblocking traffic (see Application Control)

• activating / deactivating rulesets (see Application Control)

• Configuring Alerts

Changes that need to be committed and activated

Changes to application mapping and changes to a ruleset don’t become active immediately. This avoids the risk of interrupting your running web application by incomplete settings.

Changes to application mapping or to a ruleset must be explicitly committed so that vWAF stores them in its database permanently

ATTENTION
All changes that you don’t commit are lost when you log out or close the browser! Note that you may also be logged out automatically by the system. In this case, all uncommitted changes are lost as well!

When there hasn’t been any activity within the administration interface for some time, a warning message appears on the status display, showing you how much time remains until automatic logout. However, note that you don’t see this warning if you’ve opened another tab in your browser or if another window covers the vWAF administration user interface. Also note that automatic logout might happen while you’re away from your desk or busy with some other tasks. So make it a habit to commit all changes as soon as they’re finished.

Changes to application mapping are everything that you do on the Application Mapping page.

Changes to rulesets include in particular:

• adding, deleting, and renaming paths

• adding, deleting, and renaming preconditions

• adding, deleting, and renaming individual handlers

• the automatic adding and editing of handlers by one of the wizards

Changes to application mapping become effective automatically after committing them.

Changes to rulesets only become effective if you commit and activate them. (You can also commit them without activation.) When you activate a ruleset, the ruleset that was previously active is automatically deactivated. This means that the new ruleset replaces the old ruleset and doesn’t add up to it.

In the vWAF database, you can save any number of versions of a ruleset. However, only one of these can be active at a time as a protection ruleset an one as a detection ruleset.

For more information on the process of committing and activating, see Committing and Activating Ruleset Changes and Reviewing and Discarding Ruleset Changes.

The loaded version of a ruleset and the active versions may differ

The versions active in the decider (the protection ruleset and/or the detection ruleset) don’t necessarily have to be identical with the version you’re currently configuring (the loaded ruleset).

Version Control allows you to access older versions of a ruleset at any time, and to edit and activate those versions again.

Application-specific versions of rulesets

A ruleset always relates to precisely one specific application. For the individual applications, there can be a different number of version statuses for the rulesets in question. If you’re managing multiple applications, you may have to use different version numbers for this reason.

Example

You’re managing both the applications “portal” and “webshop”. In the vWAF database, the following versions are available:

• “portal” application:

  Version1 of 1st January, Version2 of 10th February, Version3 of 14th March

• “webshop” application:

  Version1 of 1st January, Version2 of 11th February, Version3 of 10th March, Version4 of 8th April

The following could be active, for example:

• for “portal” application:

  Version2 of 10th February

• for “webshop” application:

  Version4 of 8th April

Two other versions can be loaded for editing, however. For example:

• for “portal” application:

  Version2 of 10th February (as this is also active, it would have the status “active and loaded”)

• for “webshop” application:

  Version3 of 14th March

You can find an overview of the loaded versions that are active under the menu item Home in the Applications section.