A function type rule matches a query if the query uses a function defined
in the rule. This is the desired behavior for blacklist mode operation
with `action=block`.
When in whitelist mode, all queries must match a rule to be allowed
through. For function type rules, this fact is problematic as queries that
don't use functions are blocked. The desired behavior is to allow the use
of certain functions while preventing the use of others.
The allowed set of functions should always contain the "empty set" (no
functions are used) when the filter is in whitelist mode.
The initial setting of sql_mode affects how MaxScale initially
behaves with respect to autocommit.
When 'set sql_mode=[default|oracle];" is encountered, the query
classifier and autocommit modes are adjusted accordingly.
The tee filter was missing the match/exclude functionality that was in the
previous implementation. The filter was upgraded to use PCRE2 regular
expressions instead of POSIX regular expressions.
Documented that the match/exclude patterns should use PCRE2 syntax.
The CREATE USER statement in the example document now also has a
password. This should make it more obvious that the same credentials must
work from all hosts.
MXS-1067. The CCRFilter will now look at the hints in a write-type
query. The parameter-value combinations "ccr=match" and "ccr=ignore"
are recognized and will override any regex match and ignore settings.
For the hints to work, the HintFilter needs to be present in the filter
chain before the CCRFilter.
Also ran astyle and updated documentation.
The admin interface now uses HTTP BA authentication by default. This will
prevent unrestricted access to the REST API but the authentication is by
no means secure and the HTTPS mode for the REST API should be enabled for
all production systems.
The PATCH method should now be used instead the PUT method to update
resources. As PUT request bodies should represent complete resources, the
use of PUT to update resources is no longer supported.
Altered tests to use PATCH instead of PUT for updating resources.
The tee filter now uses the local client class to clone the queries. This
imposes some restrictions on how the filter can be used but also makes
MaxScale as a whole more robust.
The module command self links now point to an endpoint that executes the
module command. Depending on the type of the module command, either a GET
or a POST request must be made.
Moved distribution specific commands to a new quickstart section, added a
copy-and-paste section for the generic commands. This should make it easier
to do a generic installation of MaxScale on a supported system.
A set of the core MaxScale parameters can now be altered at runtime. This
set consists of the authentication timeouts and the admin interface
authentication. Other parameters either can't be modified due to internal
limitations or aren't sensible to modify at runtime.
The REST API now uses the same users as MaxAdmin network interface. This
allows them to be created with MaxAdmin.
The next step is to add user creation to the REST API.
This allows MaxScale to use the PATCH functionality that's only in the
newer versions of the library. It also removes some of the problems that
exist with older systems that don't support all of the options.
