Drop external auth configuration from config.ini and move
implementation into a single backend provider named
'autologin'. This provider can strip realm names from
username with a custom regexp.
fixes#6081
Instead of having two separate functions to get the prefix
and the formatted time interval the new functions return
both the prefix and the time interval.
refs #5981
IDO version is cached in a session namespace. This fails where you
are using multiple IDO backends with different versions. We still have
no backend-specific base class where we could handle this, so for now
I continue to do so in the IdoQuery.
This patch creates one namespace per Host/dbname combination.
Even PHP code in HTML comments will be executed. As the filter object
sometimes failes, this can result in an invisible "breaking" exception.
refs #6031
We want to make use of new IDO features without breaking compatibility.
This is a quickfix as otherwise we would currently break everything
below 1.10. Code contains a few TODOs as this needs improvement.
When using list/services for show/services (services for a single host)
we us an ugly PREG-based hack fixing the base link target. This got
broken by the multiselect feature, now it's working again. We need a
better solution for this.
People used to configure something like "dot.png'> <img ..." as their
service image icon. Those hacks will no longer work as we correctly
escape everything. This fix hinders Icingaweb from even trying to load
them.
BaseQuery should no longer be abstract but be usable as is as soon as
we stripped ResultSet-specific tasks. As "Base" suggests something that
must be extended, the name no longer fits. So this is SimpleQuery right
now.
Because the `ListController' should only operate on data views,
data views should be a proxy to their underlying queries.
The methods `DataView::fromRequest()' and `DataView::sort()' are from now on deprecated
because they are relaced by `$backend->select()->from($viewName)' and `DataView::order()' respectively.
The monitoring module's ListController should only operate on data views instead of queries.
Thus the applyRestrictions() method now expects a data view instead of a query. Further since
filters are subject to change the applyRestrictions() method now does nothing.
The `hostsAction()' no longer uses `DataView::fromRequest()' but selects the data view from
a monitoring backend. `DataView::fromRequest()' orders the underlying query which must be reworked
in the current scenario.
This partially reverts fcf7f7d6. The original intention was to have
no library code reading config. Moving code snippets to another lib
doesn't solve this. We need quick & easy access to a monitoring
backend, on CLI, in other modules and so forth. Duplicating so much
code again and again is not an option.
I prefer the former way of doing things unless we find a better
solution.
