Feature - Update API for schedule (2/3)

[sasirven]

This is the API part of the schedule management with cron, which depends on https://github.com/mitre/caldera/pull/3025

Linked Merge Requests: https://github.com/mitre/caldera/pull/3025 https://github.com/mitre/magma/pull/61

• Update the operation schema:
  • Make the obfuscator required.
• Update the schedule schema:
  • Add some metadata to the schedule field for Swagger documentation. (The string type and required attribute are from the 1st Pull Request)
  • Add a cron validation for the schedule field to ensure it is a valid standard cron expression.
• Fix the operation creation:
  • Manually change the UUID to ensure the creation of a new operation. (the deepcopy also copies the existing UUID)
  • Add the creation date to the name for better readability.

[elegantmoose]

@sasirven we are picking this up now. Apologies for delay.

[uruwhy]

Out of curiosity, what is the motivation behind making the obfuscator required rather than using the default value?

[sasirven]

Out of curiosity, what is the motivation behind making the obfuscator required rather than using the default value?

As far as I remember, the default value is “plain-text,” but I’m not sure if this default value is directly available in the API. We need to add a plugin, that's right? By making the obfuscator required in the API, it would allow the user to use the API without the GUI and potentially have another plugin that does not have the "plain-text" value.

[uruwhy]

Out of curiosity, what is the motivation behind making the obfuscator required rather than using the default value?

As far as I remember, the default value is “plain-text,” but I’m not sure if this default value is directly available in the API. We need to add a plugin, that's right? By making the obfuscator required in the API, it would allow the user to use the API without the GUI and potentially have another plugin that does not have the "plain-text" value.

plain-text is the default obfuscator and is provided by the stockpile plugin, which is installed and enabled out-of-the-box and is used in the vast majority of scenarios. I imagine this change would address the edge case where a user does not have the stockpile plugin enabled for whatever reason, and thus would have to specify an obfuscator to avoid generating errors. On the other hand, making the obfuscator required 100% of the time would disrupt users that currently do not specify one in order to leverage the default value. I'm personally leaning more towards keeping it as-is (not required), since anyone who currently uses the operations/schedule API but does not use the stockpile plugin would have to specify the obfuscator anyway, and they would already be aware of that.

@clenk @elegantmoose any additional thoughts?

[sasirven]

Out of curiosity, what is the motivation behind making the obfuscator required rather than using the default value?

As far as I remember, the default value is “plain-text,” but I’m not sure if this default value is directly available in the API. We need to add a plugin, that's right? By making the obfuscator required in the API, it would allow the user to use the API without the GUI and potentially have another plugin that does not have the "plain-text" value.

plain-text is the default obfuscator and is provided by the stockpile plugin, which is installed and enabled out-of-the-box and is used in the vast majority of scenarios. I imagine this change would address the edge case where a user does not have the stockpile plugin enabled for whatever reason, and thus would have to specify an obfuscator to avoid generating errors. On the other hand, making the obfuscator required 100% of the time would disrupt users that currently do not specify one in order to leverage the default value. I'm personally leaning more towards keeping it as-is (not required), since anyone who currently uses the operations/schedule API but does not use the stockpile plugin would have to specify the obfuscator anyway, and they would already be aware of that.

@clenk @elegantmoose any additional thoughts?

This leads me to another question: If a user does not use the default value and makes a direct call to the API, will the obfuscator later be set with the default value, i.e., plain-text? Or are you only referring to the GUI that sets the default value? Because in this case, technically, the GUI will fill the obfuscator with the default value right?

[uruwhy]

Out of curiosity, what is the motivation behind making the obfuscator required rather than using the default value?

As far as I remember, the default value is “plain-text,” but I’m not sure if this default value is directly available in the API. We need to add a plugin, that's right? By making the obfuscator required in the API, it would allow the user to use the API without the GUI and potentially have another plugin that does not have the "plain-text" value.

plain-text is the default obfuscator and is provided by the stockpile plugin, which is installed and enabled out-of-the-box and is used in the vast majority of scenarios. I imagine this change would address the edge case where a user does not have the stockpile plugin enabled for whatever reason, and thus would have to specify an obfuscator to avoid generating errors. On the other hand, making the obfuscator required 100% of the time would disrupt users that currently do not specify one in order to leverage the default value. I'm personally leaning more towards keeping it as-is (not required), since anyone who currently uses the operations/schedule API but does not use the stockpile plugin would have to specify the obfuscator anyway, and they would already be aware of that. @clenk @elegantmoose any additional thoughts?

This leads me to another question: If a user does not use the default value and makes a direct call to the API, will the obfuscator later be set with the default value, i.e., plain-text? Or are you only referring to the GUI that sets the default value? Because in this case, technically, the GUI will fill the obfuscator with the default value right?

The operation constructor uses plain-text as the default obfuscator value. So if you use the API to create an operation and don't specify the obfuscator, it will default to that value (which is how I created operations to test the scheduler in updates in https://github.com/mitre/caldera/pull/3025).

[elegantmoose]

Thank you @sasirven !