Source: Introduce Usernames #338
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a first version to move the rule evaluation from Icinga Notifications into the source, starting with Icinga DB. For an end user or another computer, the /process-event API endpoint was slightly modified. Two new HTTP request headers were introduced to tell which rules match and to share the state. Another new /event-rules API endpoint allows querying all rules.
Instead just use a regular non-json-serializable field similar to how we already do it for `Time` and `SourceId`.
Instead of having to determine the rules version with each incoming request by the listener, we can just make use the already existing incremental update mechanism to keep the version up-to-date. This way, the version will only be updated when a rule is added, changed, or deleted, so there will be no performance impact on the listener side. Apart from that, the listener responds and verifies the rules version on a per-source basis now. As required by the internal document, event rules will be tied to their source because only this source knows how to evaluate them. Therefore, the database `rule` table has been extended to include a `source_id` column, and consequently, each source will only receive the rules that are relevant to it. Thus, initially, when a source submits an event, it will likely be rejected but at the same time receive the current rules, so it can retry the event submission with the correct event rules. This way, no extra HTTP request is needed to fetch the rules, as we will always respond with the newest ones whenever we detect that they're using an outdated event rules config.
I think, this better describes the use case than using the `424` HTTP status code.
WIP because we might move the code elsewhere.
Synchronize codebase against latest version of Icinga/icinga-go-library#145, containing package changes.
Move the bcrypt password comparison up to the Source and introduce a cache there. This reduces the expensive bcrypt calls by a lot, reducing the authorization delay from round about two seconds to single-digit milliseconds on my machine. On a similar note, we should consider changing the API to allow creating some token after an initial password authorization instead of passing the authentication data all the time.
- Update IGL to include rules and rule versions in the event. Thus, being available in JSON and no longer in a HTTP header. - Simplify schema rule version incrementation logic by ignoring the edge case of sources w/o rules. In this case, the rule will not be reset, but further incremented. - Fix import names. - Abort processing incoming events for unknown rules. This could only occur if there is a race between changing rules and a processed event, as rules are initially checked. - Erase race condition between mutex locks and unlocks for HTTP rule endpoint and ensure debug dump rules has a mutex all the time. - Change the SQL CHECK for the listener_password_hash to allow different versions of bcrypt. The "$2y$" thingy is PHP specific to highlight "old" bcrypt passwords being affected by a PHP implementation bug, not a bcrypt specification bug or change.
- event.Event: Extend baseEv.Event instead of a pointer. - object: Merge IdTagRow and TagRow. - objects.go: Remove mysterious trailing whitespace.
Unique usernames were added to Sources for HTTP Authentication. Before, the HTTP Authentication expected a username based on the Source ID, such as "source-23". This was not very practical. Thus, an unique username column was introduced and the Listener's authentication code was adequately altered. Fixes #227.
oxzi
force-pushed
the
source-listener-username
branch
from
9e07bb4 to
85e43f8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Unique usernames were added to Sources for HTTP Authentication.
Before, the HTTP Authentication expected a username based on the Source ID, such as "source-23". This was not very practical. Thus, an unique username column was introduced and the Listener's authentication code was adequately altered.
Fixes #227.
This PR shows against the
icingadb-sourcebranch (PR #324) for the moment as this other PR already made relevant changes. After #324 was merged, I would rebase and point this PR againstmain.