[
https://issues.apache.org/jira/browse/RANGER-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyom Mani Tiwari updated RANGER-5742:
-------------------------------------
Description:
Service configuration read/write logic decides how a config value is displayed
and stored by comparing its key against a single hardcoded field name, instead
of consulting that field's declared type in the service definition. Service
definitions can mark other fields with the same type under different names, and
those fields don't get the same handling as the hardcoded one.
*Details*
* Affects: {{security-admin}} ({{{}RangerServiceService{}}},
{{{}ServiceDBStore{}}})
* Both the read path (service config retrieval) and the write path (service
config storage) compare a config key against one fixed string rather than
looking up the field's declared type from the service definition.
* Result: behavior is inconsistent across service types — fields with the same
declared type are handled differently purely because of their name.
* Confirmed for two service definitions, where two fields per definition share
the same declared type as the hardcoded field but use different names.
was:
ervice configuration read/write logic decides how a config value is displayed
and stored by comparing its key against a single hardcoded field name, instead
of consulting that field's declared type in the service definition. Service
definitions can mark other fields with the same type under different names, and
those fields don't get the same handling as the hardcoded one.
*Details*
* Affects: {{security-admin}} ({{{}RangerServiceService{}}},
{{{}ServiceDBStore{}}})
* Both the read path (service config retrieval) and the write path (service
config storage) compare a config key against one fixed string rather than
looking up the field's declared type from the service definition.
* Result: behavior is inconsistent across service types — fields with the same
declared type are handled differently purely because of their name.
* Confirmed for two service definitions, where two fields per definition share
the same declared type as the hardcoded field but use different names.
> Inconsistent handling of service config fields by name vs. declared type
> ------------------------------------------------------------------------
>
> Key: RANGER-5742
> URL: https://issues.apache.org/jira/browse/RANGER-5742
> Project: Ranger
> Issue Type: Bug
> Components: admin
> Affects Versions: 2.8.0, 2.9.0
> Reporter: Vyom Mani Tiwari
> Assignee: Vyom Mani Tiwari
> Priority: Critical
> Fix For: 3.0.0
>
>
> Service configuration read/write logic decides how a config value is
> displayed and stored by comparing its key against a single hardcoded field
> name, instead of consulting that field's declared type in the service
> definition. Service definitions can mark other fields with the same type
> under different names, and those fields don't get the same handling as the
> hardcoded one.
> *Details*
> * Affects: {{security-admin}} ({{{}RangerServiceService{}}},
> {{{}ServiceDBStore{}}})
> * Both the read path (service config retrieval) and the write path (service
> config storage) compare a config key against one fixed string rather than
> looking up the field's declared type from the service definition.
> * Result: behavior is inconsistent across service types — fields with the
> same declared type are handled differently purely because of their name.
> * Confirmed for two service definitions, where two fields per definition
> share the same declared type as the hardcoded field but use different names.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
