Open james-stevens opened 2 years ago
The "charade" as you describe it was built to avoid exactly the problems you describe. I.e. there is no point of assigning multiple values to SOA-EDIT, SOA-EDIT-API, etc., and the facade is intended to allow only valid settings. IIRC at some point this got relaxed, and now some metadata is visible as metadata and via the facade, leading to new problems.
But the protection you describe only works via the API - i.e. the protection can still be violated by direct SQL changes to METADATA
However, if the user is only updating the METADATA via the API, then all the protection you describe can still be applied via the METADATA update calls.
So I don't really buy this argument.
But the protection you describe only works via the API - i.e. the protection can still be violated by direct SQL changes to METADATA
Sure, but this is also true if you use a hex editor on your database files.
However, if the user is only updating the METADATA via the API, then all the protection you describe can still be applied via the METADATA update calls.
That makes for a very weird API.
That makes for a very weird API
That ship already sailed - with some METADATA addressed as real METADATA and some as fake zone properties, as well as having some real zone properties.
RRs are validated when submitted via the API - I don't see how validating METADATA is any different.
In fact I'd say it's weird that you DON'T validate API submitted METADATA.
Are you really trying to argue that validating METADATA value, when submitted via the API, would be a bad idea? Its a case to be made, but not one I would support.
IMHO, having all METADATA treated as METADATA, and correctly validated, would be a simplification of what you currently have.
All this refers to the REST/API.
Since 4.6.X
SOA-EDIT
can now be addressed as either the zone propertysoa_edit
OR the metadata itemSOA-EDIT
. When addressed as a metadata item you can assign it multiple values, but clearly it should only ever have one value, or no value. The first item in the metadata list is the one that appears when asking for the zone propertysoa_edit
.When addressed as the zone property
soa_edit
you can't delete its value, only set it to an empty string & its not clear if this will mean the server will fall back to using the system/conf default or not. You can delete it when addressing it as the metadata itemSOA-EDIT
SOA-EDIT-API
can only be addressed as the zone propertysoa_edit_api
& its value can not be deleted, only set to blank. When other zone properties are set to blank, this causes the corresponding metadata item to get deleted, but not forsoa_edit_api
orsoa_edit
.There are various metadata items, for example those that have boolean values, that can be given multiple values, but clearly should not. This also applies to all the
SOA-EDIT*
items, for example. Having an item bothtrue
andfalse
is very quantum mechanics, but probably not anybody wants.Although
SOA-EDIT
can now be addressed as a metadata item, other metadata items that are faked to appear as if they are zone properties are not allowed to addressed as the metadata they really are:SOA-EDIT-API
,NSEC3PARAM
,TSIG-ALLOW-AXFR
&AXFR-MASTER-TSIG
Environment
Other information
PERSONALLY, I think you should drop the whole "zone properties" charade, as only
kind
& the zone name are real zone properties, the rest are all implemented (in the database) as metadata values - therefore users SHOULD be allowed to address them, in the API, as the metadata they really are - instead you give the error message "Not a metadata item" when that's exactly that they really are !?!?!?!?