+1I have the following code in place to find a case by it's ID:
siemplify.get_cases_by_filter(case_ids_free_search="276")
Your documentation tells me this will return a list of case IDs (I think, it's not entirely clear), however no matter what ID I search this is what is returned:
{"dummy": "publisher"}
Why does this happen / what am I doing incorrectly?
+10@jeferest I've tried very similar code (with Python3.9 and Python3.11) in our lab and wasn't able to reproduce an issue. I recommend you to inspect other parts of your code and if issue is still occurring open a Support Ticket.
Dummy code that I've used:
from SiemplifyAction import SiemplifyAction
from SiemplifyUtils import unix_now, convert_unixtime_to_datetime, output_handler
from ScriptResult import EXECUTION_STATE_COMPLETED, EXECUTION_STATE_FAILED,EXECUTION_STATE_TIMEDOUT
@output_handler
def main():
siemplify = SiemplifyAction()
cases = siemplify.get_cases_by_filter(case_ids_free_search="166958")
print(cases)
status = EXECUTION_STATE_COMPLETED
output_message = "output message :"
result_value = True
siemplify.LOGGER.info("\\n status: {}\\n result_value: {}\\n output_message: {}".format(status,result_value, output_message))
siemplify.end(output_message, result_value, status)
if __name__ == "__main__":
main()
+5Hey,
With the return data being
{"dummy": "publisher"}Is the integration instance you are writing the action under set to "run remotely"?
You can check this by finding the instance listed in "intergration setup" and seeing if the "Run remotely" checkbox is ticked.
I've not used remote agents for a very long time, but what I can remember is that they are essentially barebones SOAR installs - is it possible that the code is running under the context of the remote agent which is why it cannot find any data associated with the search?
If this is the case I would recommend creating a seperate custom integration where you develop locally run actions or create a new instance of the integration configuration with run remotely unticked..
Cheers
Kyle
+1Hey,
With the return data being
{"dummy": "publisher"}Is the integration instance you are writing the action under set to "run remotely"?
You can check this by finding the instance listed in "intergration setup" and seeing if the "Run remotely" checkbox is ticked.
I've not used remote agents for a very long time, but what I can remember is that they are essentially barebones SOAR installs - is it possible that the code is running under the context of the remote agent which is why it cannot find any data associated with the search?
If this is the case I would recommend creating a seperate custom integration where you develop locally run actions or create a new instance of the integration configuration with run remotely unticked..
Cheers
Kyle
Hi Kyle, thanks for your answer. Yes, this is being run as a remote connector, which is needed to access resources in my company's network. Running locally within the cloud instance is not an option, but I need to be able to locate and make changes to cases from the connector. Is there a way to do that?
Thanks,
Jeff
+5Hi Kyle, thanks for your answer. Yes, this is being run as a remote connector, which is needed to access resources in my company's network. Running locally within the cloud instance is not an option, but I need to be able to locate and make changes to cases from the connector. Is there a way to do that?
Thanks,
Jeff
Ah I see Jeff!
Not a problem, I think this is still doable but it will require extra code - essentially we would need to generate an API token with sufficient privileges (within your cloud instance) to perform the operations you are wanting to under take - and then write our own function to ensure the api call is going to the cloud instance from the remote agent.
By the look of it, the siemplify class will be using the API_ROOT of the publisher at the moment, so aslong as we make our function call direct to the cloud for any case related interactions we should be okay.
Unfortunately I do not have access to my SOAR instance at the moment so if anyone can provide a more verbose solution that would be great - but ill provide a more detailed response in due course otherwise!
Cheers
Kyle
+5Hi Jeff,
So I've ended up actually going on a rabbit hole on this one - and I've found the cause of the above data returning in the SOAR SDK documentation:
In SIemplifyBase.py - there is a check to see if the action is running on publisher mode here
# Create regular Session
self.session = requests.Session()
self.session.verify = False
HEADERS.update({"AppKey": self.api_key})
self.session.headers.update(HEADERS)
else:
# Create custom Session
# Publisher mode not send the requests
self.session = SiemplifySession()SiemplifySession is imported from https://github.com/chronicle/soar-sdk/blob/main/SiemplifyPublisherUtils.py
there's a snippet of code here that addresses the return data you are seeing:
# override post
def post(self, address, data=None, json=None, **kwargs):
if json:
request_data = json
elif data:
request_data = data
else:
request_data = {}
self.write_rest_calls_to_file(address, request_data)
# Return response to support validate_error func
res = requests.Response()
# override content to support response.json()
res._content = '{"dummy": "publisher"}'
# override status to support comparing status codes
res.status_code = 200
return resHere we can see that any response content is overridden to '{"dummy":"publisher"}' which shows why your code snippet is returning the data that it is. Unfortunately I don't know enough about publishers to understand what happens to the written requests (presumably they are handled seperately to avoid the issues I previously mentioned).
With that in mind - I think my work around would probably cause issues in the long run - and a support ticket as @f3rz mentioned is the best way forward, as it seems there should already be a mechanism to deal with the problem.
Apologies that I couldn't get you a solid answer!
Cheers
Kyle
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.