was begun by frank7y. Added some unit tests.
Also address a design flaw which prevented the AST builder
function create_pattern_object() from honoring module_suffix
and module_name parameters after the first call.
Previously the requirement that properties ending in `_ref(s)` were
instances of an appropriate type capable of containing a STIX
`identifier` (the current interpretation of section 3.1 of the STIX 2.1
spec) was only enforced for custom observables. This change refactors
the property checks for custom objects to enforce this and the STIX 2.1
property name requirement (also from section 3.1) in a common helper,
therefore extending the enforcement of both requirements to all custom
object types created by downstream projects.
There is a special case carved out for STIX 2.0 observables which are
required to contain "object references" rather than identifiers. This
special logic is encoded in the reference property validation helper and
enabled by a kwarg which is passed exclusively by the custom observable
registration helper.
and process properties in that order. This establishes iteration
order on object properties, making the object_properties() method
unnecessary. So the latter method has been deleted. All uses
of that method have been removed.
Removed unnecessary deepcopy() in STIXJSONEncoder, to improve
efficiency. This uncovered a bug which had been affecting
STIXdatetime instances. Not deepcopying doesn't trip the bug,
which can change serialization format. This caused a unit
test to fail, which was checking serialization format. I fixed
the unit test.
Fixed a bug in _STIXBase.__repr__ which caused it to omit all
properties with falsey values. This caused several unit tests
to break, since they were written against the old buggy repr
format. Notably, 'revoked=False' was never included in reprs
before, but it is now.
fixes.
- Fixed bugged logic in _STIXBase._check_at_least_one_property(),
and revamped the code to be simpler and clearer.
- Changed custom extension registration to auto-create an
"extension_type" property based on the attribute of that
name on the custom class, if present.
- The custom extension registration change above uncovered
what seemed like a bug in a unit test: a custom extension
was registered, but it was not given an extension type. The
test used the extension as extension_type="property-extension";
this now causes a standard error about an extra property. I
fixed the test to assign the custom extension the proper type.
- Changed an error message "Cannot determine extension type."
At that point in the code, we in fact have a registered
extension type and the class for it, so it didn't seem to make
any sense. I changed it to say that an extension of that type
couldn't be created from type of value given. Because this is
really about typing (in both the old and new code), I also
changed the exception class to TypeError.
- Changed customization behavior: unregistered
"extension-definition--" style extensions are no longer
considered custom. Their mere presence can no longer be
considered a customization, since it doesn't fit the
criteria, and in fact the extension mechanism is supposed to
supplant the old customization system anyway. Unregistered
extensions of other types are still considered custom.
- Fixed up unit tests according to the exception message
change.
- Added a unit test for unregistered "extension-definition--"
style extensions.
The "loophole" occurs when an object contains an unregistered top-level
extension. Since it's unregistered we can't tell if any custom
properties on the object were defined in that extension so we assume
that they are.
constraints (i.e. both generic type categories and specific
types). Also:
- more expansion/refinement of reference property unit tests
- bugfix: SROs are in OBJ_MAP too, it's not just SDOs! Oops...
- pre-commit stylistic fixes
assert prop.clean(...)
doesn't test well enough since clean() methods on this branch
produce 2-tuples, and you should test what's in the tuple, not
just that it returned something non-empty. So I fixed it in
several places to test the tuple contents.
work when a whitelist of generic category types is used.
Disallow hybrid constraints (both generic and specific at the
same time). Add more unit tests.
thought it should, but forgot to fix Report to use
ReferenceProperty in the way I thought it should! Oops.
Added some tests to ensure Report is working property with
custom ID types in object_refs.
and dicts, and add better raised exception types if versioning
couldn't be done. I changed workbench monkeypatching a bit, to
copy some class attributes over to the workbench wrapper
class-like callables, since some code expected those attributes
to be there (e.g. the versioning code).
dict/mapping values: do a simple verification of the value's
STIX version, not just its type. Added a lot more unit tests to
test behavior on dicts. To make the implementation work, I had
to move the detect_spec_version() function out of the parsing
module and into utils. So that required small changes at all
its previous call sites.
Christian Studer