If the authenticator option is enabled, no users are loaded and no errors
have occurred in the user loading process, the service credentials are
injected.
The result of the authentication should be ignored but the scramble that
is calculated as a side-effect still needs to be stored. This can be done
by altering the SQL used to get the matching row to only match on the
username, not the network address.
Also expanded the test case to cover the use of bad credentials.
Cleaned up the MaxScale version of the mysql.h header by removing all
unused includes. This revealed a large amount of dependencies on these
removed includes in other files which needed to be fixed.
Also sorted all includes in changed files by type and alphabetical
order. Removed explicit revision history from modified files.
The type of the user being created is defined at creation time. This
allows the creation of basic users.
Although the users can be created internally, they cannot yet be created
via maxadmin or the REST API.
The refactored interface is now in use. The only module that used it
directly was the CDC protocol module. This should probably be changed so
that it uses the adminusers interface instead of the users interface
directly.
Divided functionality into classes, fixed comments +
various other cleanup. BackenAuth no longer increments
sequence on sending password. SQLite busy timeout shortened
to 1 second.
This includes the client and backend authenticators. Currently,
only a simple password-based scheme with the SQL-client "dialog" plugin
is supported. In this mode, the server sends the first PAM message
with the AuthSwitchRequest packet and the client responds with the
password. No further authentication messages are supported. If the
connection is not encrypted, the password is sent in plaintext. The
client password is used as is for logging in to backends.
The function should actually be in include/maxscale/protocol/mysql.h
and the implementation in MySQLCommon, but the monitors do not link
to that yet.
All MySQL related should be moved to MySQLCommon and the core
refactored so that no MySQL knowledge is needed there.
With this change, it is no longer possible that the server version
is deallocated at the very moment it is read. There is still a race,
but it's mostly harmless.
The module commands can now produce JSON formatted output which is passed
to the caller. The output should conform to the JSON API as closely as
possible.
Currently, the REST API wraps all JSON produced by module commands inside
a meta-object of the following type:
{
"meta": <output of module command>
}
This allows the output to be JSON API conformant without modifying the
modules and allows incremental updates to code.
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.
If a client connects from an IPv4 address, but the listener listens on an
IPv6 address, the client IP will be a IPv6 mapped IPv4 address
e.g. ::ffff:127.0.0.1. A grant for an IPv4 address should still match an
IPv6 mapped IPv4 address.
When users were loaded, the permissions for the service user were
checked. The conditional that makes sure the check is executed only at
startup was checking the listener's users instead of the SQLite handle
which caused all reloads of users to check the permissions.
When log messages are written with both address and port information, IPv6
addresses can cause confusion if the normal address:port formatting is
used. The RFC 3986 suggests that all IPv6 addresses are expressed as a
bracket enclosed address optionally followed by the port that is separate
from the address by a colon.
In practice, the "all interfaces" address and port number 3306 can be
written in IPv4 numbers-and-dots notation as 0.0.0.0:3306 and in IPv6
notation as [::]:3306. Using the latter format in log messages keeps the
output consistent with all types of addresses.
The details of the standard can be found at the following addresses:
https://www.ietf.org/rfc/rfc3986.txthttps://www.rfc-editor.org/std/std66.txt
When MaxScale is being started and the users are loaded, the MySQL
authenticator should not load the database users for internal services
abstracted as servers.
The loading of users at startup for internal services is avoided because
the startup is done in a single thread context and the internal services
have not yet been started.
The delayed loading of users will cause the authentication to fail when
the first client connect. This triggers the reloading of the users and the
second attempt at authentication will succeed. All of this is hidden from
the end user.
If a server points to a local MaxScale listener, the permission checks for
that server are skipped. This allows permission checks to be used with a
mix of external servers and internal services.
The static module capabilities are now used to query the capabilities of
filters and routers. The new RCAP_TYPE_NOAUTH capability is also taken
into use. These changes removes the need for the `is_internal_service`
function.
The static capabilities declared in getCapabilities allows certain
capabilities to be queried before instances are created. The intended use
of this capability is to remove the need for the `is_internal_service`
function.
The connector plugin directory can now be controlled with the
`connector_plugindir` argument and configuration option. This should allow
the connector to use the system plugins if the versions are binary
compatible.
Replaced calls to mysql_options to mysql_optionsv as the former is
deprecated in Connector-C 3.0 and the latter is supported in Connector-C
2.3.
The client protocol module can resolve whether a password was used based
on the information the authenticators gather before authentication is
done. It uses the authentication token length as the basis on which it
makes the decision.
The users were deleted before each individual server was queried. This
caused authentication to fail if the authentication data was loaded from
multiple servers.
