Skip to content

Commit ecfd767

Browse files
authored
Fix empty or incomplete object customvars (#1332)
fixes #1331
2 parents db3f6e7 + 1ed5612 commit ecfd767

3 files changed

Lines changed: 31 additions & 6 deletions

File tree

doc/05-Upgrading.md

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,31 @@
33
Specific version upgrades are described below. Please note that version upgrades are incremental.
44
If you are upgrading across multiple versions, make sure to follow the steps for each of them.
55

6+
## Upgrading to Icinga DB Web v1.4
7+
8+
**Behavior Changes**
9+
10+
Modules that provide integrations for a host's or service's detail view now have unrestricted access to all custom
11+
variables of said object. This is the case by accessing custom variables via the object's `customvars` property.
12+
This was always meant to be the case, but due to an implementation oversight, the restrictions configured via
13+
`icingadb/filter/objects`, `icingadb/filter/hosts` and `icingadb/filter/services` were applied and caused
14+
unexpected or erroneous behavior. Though, in some cases this may not have been noticed or seen as a problem,
15+
so when upgrading we recommend to review modules that provide such integrations and check if they rely on the
16+
previous behavior. If so, accessing the `vars` property of an object should have the desired effect.
17+
18+
The following modules made by Icinga are safe and do not need an update to still work:
19+
20+
* Icinga Business Process Modeling
21+
* Icinga Web Graphite Integration
22+
23+
Cases where this may not have been noticed are as follows:
24+
25+
* Restrictions only reference `host.*` columns and integrations only require access to host variables.
26+
* Restrictions only reference `service.*` columns and integrations only require access to service variables.
27+
28+
Since these are very specific cases, we don't expect broad expectation of the previous behavior, but please review
29+
your setup nonetheless if you use third party or custom modules that access custom variables this way.
30+
631
## Upgrading to Icinga DB Web v1.3
732

833
**Requirements**

library/Icingadb/Model/Host.php

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -236,9 +236,9 @@ public function createDefaults(Defaults $defaults)
236236
});
237237

238238
$defaults->add('customvars', function (self $subject) {
239-
if (! $subject->customvar instanceof ResultSet) {
240-
$this->applyRestrictions($subject->customvar);
241-
}
239+
// In contrast to customvar_flat, we cannot apply restrictions here as denylists and protections
240+
// require the flattened values to work. To retrieve only customvars the user has access to, the
241+
// `vars` property should be used instead.
242242

243243
$vars = [];
244244
foreach ($subject->customvar as $customVar) {

library/Icingadb/Model/Service.php

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -228,9 +228,9 @@ public function createDefaults(Defaults $defaults)
228228
});
229229

230230
$defaults->add('customvars', function (self $subject) {
231-
if (! $subject->customvar instanceof ResultSet) {
232-
$this->applyRestrictions($subject->customvar);
233-
}
231+
// In contrast to customvar_flat, we cannot apply restrictions here as denylists and protections
232+
// require the flattened values to work. To retrieve only customvars the user has access to, the
233+
// `vars` property should be used instead.
234234

235235
$vars = [];
236236
foreach ($subject->customvar as $customVar) {

0 commit comments

Comments
 (0)