The User class now only exposes the `match` method which can be used to
check if any of the rules for a user match a query. Further cleanup is
required once individual rule classes have been implemented.
The User class now handles the appending of the rules by itself and it
also provides a method for accessing the name instead of exposing the name
itself.
The rules matching is still done externally to the User class and moving
it into the User class depends on other changes being made first.
The core declarations of the dbfwfilter are in dbfwfilter.hh, the rules in
rules.hh and the users in users.hh. The implementation of the rules is in
rules.cc.
The Rule base class now checks whether the query needs to be fully parsed
and if the type of the query matches the rule.
Also added a base rule matching method that should be extended by the rule
types to do their matching. Currently no rule type uses it.
The users are now stored in a unordered_map which removes the need for the
use of HASHTABLE. Altered all functions to use a shared_ptr of a User
instead of a raw pointer. Made parsing of rules exception-safe.
The rules are now stored in a list instead of a linked list of
rules. Parts of the code still use raw pointers to the Rule class instead
of shared pointers.
All value lists in the dbfwfilter rule grammar followed the same general
rules; they allowed virtually all types to be given. The minor differences
aren't large enough to warrant use of multiple list types.
The user templates now use ValueList instead of STRLINK to store the
string values and they are stored as a list of shared pointers.
Minor cleanups to the user creation related grammar rules.
The rules are now created when all the information has been gathered. This
way of parsing is better suited to parsing objects and allows the
dbfwfilter rules to be eventually refactored into C++ classes.
The current code still uses structs to define the rules but it makes the
migration to classes easier.
The uses_function type rule matches when any of the columns given as
values uses a function. With this, columns can be denied from being used
with a function.
It is now possible to specify the thread stack size to be used,
when a new thread is created. This will subsequently be used
for allowing the stack size to be specified for worker threads.
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.
The qlafilter exposes the unified log file as a module command that
outputs an array of JSON strings, one for each line in the file. The
command takes two optional parameters, the start and end lines for the log
file.
Further improvements could be done to allow reading of session specific
log files.
Some sort of an authorization scheme for the REST API should be
implemented to limit the possibility of exposing unwanted parts of the
REST API.
The query classifier should only be used to parse text protocol
statements. The insertstream filter exploited the fact that any statements
that the filter did not expect would be classified as an unknown
commands. This led to repetitive error messages with binary protocol
statements.
The keyword in the Json is now "match" and MatchRule class substitutes
CaptureRule
"replace": {
"column": "d_code",
"match": "(?<=aaa).*(?=-12)|(?<=-12).*"
},…
If a rule is defined with only an optional part, it should be of the
permission type. This type is used to signal that the rule matches if the
optional constraints are fulfilled.
Due to refactoring, the default type was changed from RT_PERMISSION to
RT_UNDEFINED.
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.
