Cleaned up the documentation and reformatted the parameter list of
listener creation to be made out of links.
Added some comments to the resource declarations in resource.cc to prevent
the order of them from being altered.
The servers resource now shows the SSL parameters in the example
output. It also lists the parameters in the list of valid values for
parameters in the server creation section.
Updated documentation generation script and regenerated documentation. Now
all command documentation is generated by using the output of the `help`
commands.
If the session id is known, it will be logged together with all
messages. If present, the session id appears, enclosed in paranthesis,
right after the message category. E.g.
2017-08-30 12:20:49 warning: (4711) [masking] The rule ...
If the session id is known, it will be logged together with all
messages. If present, the session id appears, enclosed in paranthesis,
right after the message category. E.g.
2017-08-30 12:20:49 warning: (4711) [masking] The rule ...
The `add user` and `enable account` commands create fully privileged
administrative users like they did in 2.1. This makes the addition of
read-only users backwards compatible.
Updated and expanded the documentation on administrative interface
users. Added entries into the release notes as well as the upgrading
document about relevant changes between 2.1 and 2.2.
The users are now stored as an array of JSON objects. Legacy users are
automatically upgraded once they are loaded and a backup of the original
users file is created.
Removed the password parameter from the `remove user` maxadmin command as
well as all of the relevant functions. Requiring that an administrator
knows the password of the account to be deleted is not a sound requirement
now that, at least in theory, two types of accounts can be created.
Having bugs and issues listed separately has its benefits over listing
everything. The same output can still be achieved by running both scripts
and concatenating their output.
Disabling the tee filter at runtime is desirable for cases where the
branched service is not always needed. Migrations and pre-production
setups are one where changes to the branched service are expected and
splitting the queries would result in an error.
The function type rule now accepts an empty list of functions, allowing
all functions to be blocked by defining an empty function type rule and
setting action=allow.
