With the integration of Helios, we lose one of the features some of the new users needed to go through: getting approval for a new blacklist term or pattern.
We need a UI in metasmoke that can be used by users of the appropriate permission level to approve or deny a new blacklist item.
Options:
Send blacklist requests that require approval to Helios, but add an inactive flag. Metasmoke UI will approve the change and send an update which will remove the flag. At that point the blacklist item will appear in all calls to Helios. This will require:
An endpoint on Helios to pull inactive items
An update to the blacklist endpoints to not return inactive items
An end point on Helios to update specific items
An end point on Helios to deny a specific item (probably combined with the above with an approve/deny flag)
A metasmoke screen to approve/deny a blacklist item
Send blacklist requests that require approval to metasmoke and only forward approvals to Helios. This will require:
A metasmoke screen to approve deny a blacklist item
A database change to metasmoke to hold these requests temporarily
I'm curently working on this locally -- I opted for option #2 since Smokey already knows whether the invoker has code admin and can easily send the request to either Helios or Metasmoke.
With the integration of Helios, we lose one of the features some of the new users needed to go through: getting approval for a new blacklist term or pattern.
We need a UI in metasmoke that can be used by users of the appropriate permission level to approve or deny a new blacklist item.
Options:
Send blacklist requests that require approval to Helios, but add an inactive flag. Metasmoke UI will approve the change and send an update which will remove the flag. At that point the blacklist item will appear in all calls to Helios. This will require:
Send blacklist requests that require approval to metasmoke and only forward approvals to Helios. This will require: