Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Presentation of redefined attributes types in objects is incorrect #76

Open
rmouritzen-splunk opened this issue Mar 4, 2024 · 0 comments
Assignees
Labels
bug Something isn't working

Comments

@rmouritzen-splunk
Copy link
Contributor

rmouritzen-splunk commented Mar 4, 2024

In cases where an object attribute's type is redefined or refined by specifying a value for type that is different than the dictionary's type, and a caption attribute is no also supplied, the type name shown in the "Type" column for the attribute on the object's page -- at the /objects/:id URL -- incorrectly shows the type name from the dictionary and not the type name associated with redefined type.

Example:
The presentation of the Fingerprint object's type in the "Type" column on the /objects/fingerprint page incorrectly shows the type name "String" -- the type of value in the dictionary. The Fingerprint object refines the type of value to file_hash_t, which has a type name of "Hash" in the dictionary.

Note: The human-readable type_name is incorrect. The actual type in the type property is correct. This (probably) only affects how the OCSF Server presents this information. Other uses (hopefully) only use the type property.

The suspected cause is that the "simple" folding of the dictionary and object type information is not handling this edge case. In most cases, types are not refined / redefined in object definitions.

Cases where this happens in the 1.2.0-dev schema (most or perhaps even all of these exist in prior versions as well):

  • Fingerprint.value -- redefined as file_hash_t
  • File.name -- redefined as file_name_t
  • User.name -- redefined as username_t
@rmouritzen-splunk rmouritzen-splunk added the bug Something isn't working label Mar 4, 2024
@rmouritzen-splunk rmouritzen-splunk self-assigned this Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant