XSOAR-Web-Server

This is a simple web-server that as of now, supports handling configurable user responses (like Yes/No/Maybe) and data collection tasks that can be used to fetch key value pairs. What makes it different from Data collection tasks is that, the URL to perform a certain action is predictable and written to the incident context when an action is setup.This URL can be inserted to for eg: an HTML email. User clicks are are recorded in the integration context and can be polled by Scheduled Commands/ Generic Polling.

Utilities · Xsoar-web-server

Details

IDXSOAR-Web-Server
ProviderPalo Alto Networks
CategoryUtilities
From Version6.5.0
Docker Imagedemisto/bottle:1.0.0.10133006

README

This is a simple web-server that as of now, supports handling configurable user responses (like Yes/No/Maybe) and data collection tasks that can be used to fetch key value pairs. What makes it different from Data collection tasks is that the URL to perform a certain action is predictable and written to the incident context when an action is setup. This URL can be inserted to for example: an HTML email. User clicks are recorded in the integration context and can be polled by Scheduled Commands/ Generic Polling.
This integration was integrated and tested with version 1.0 of XSOAR-Web-Server

Configure XSOAR-Web-Server in Cortex

Parameter Description Required
Incident type   False
Long running instance   False
Server Listening Port Runs the service on this port from within Cortex XSOAR. Requires a unique port for each long-running integration instance. Do not use the same port for multiple instances. Note: If you click the test button more than once, a failure may occur mistakenly indicating that the port is already in use. (For Cortex XSOAR 8 and Cortex XSIAM) If using an engine, you must enter a Listen Port. If not using an engine, do not enter a Listen Port and an unused port will automatically be generated when the instance is saved. True
XSOAR external URL The URL on which the user should send the response to. True

Commands

You can execute these commands from the CLI, as part of an automation, or in a playbook.
After you successfully execute a command, a DBot message appears in the War Room with the command details.

xsoar-ws-setup-simple-action


setup the web server to handle URL clicks for each action specified from single or multiple recipients

Base Command

xsoar-ws-setup-simple-action

Input

Argument Name Description Required  
actions Comma-separated possible values for each action. Mandatory for get requests. Required  
emailaddresses Comma-separated email addresses of the recipients. Required  
userstring User defined string that has to be set from the playbook. This is used to differentiate between multiple jobs running on the same incident. Required  
htmltemplate   Template to construct the HTML mail. Required
xsoarproxy Used to specify what endpoint to submit the responses. If set to false, the HTML template will have the endpoint containing the custom port. Possible values are: true, false. Default is true. Optional  

Context Output

Path Type Description
WS-ActionDetails unknown The current status of the action’s configuration details.
WS-ActionDetails.job_uuid unknown Subset of action details, added for ease of configuration in playbooks.

xsoar-ws-clear-cache


Clear the backend storage containing all session information.

Base Command

xsoar-ws-clear-cache

Input

| Argument Name | Description | Required |
| — | — | — |

Context Output

There is no context output for this command.

xsoar-ws-show-cache


Show the details of all the setup actions from the backend.

Base Command

xsoar-ws-show-cache

Input

| Argument Name | Description | Required |
| — | — | — |

Context Output

There is no context output for this command.

xsoar-ws-remove-action


Remove a certain job from the backend.

Base Command

xsoar-ws-remove-action

Input

Argument Name Description Required
uuid Job’s UUID. Required

Context Output

There is no context output for this command.

xsoar-ws-get-action-status


Gets the current status of an action that was setup. Used to track if the user responded to the action.

Base Command

xsoar-ws-get-action-status

Input

Argument Name Description Required
uuid Job’s UUID. Required

Context Output

Path Type Description
WS-ActionStatus unknown The current status of the action with some configuration data. Is used for polling the status.
WS-ActionStatus.link_tracker unknown Subset of action status. Tracked here to make it easier for configuring playbooks.

xsoar-ws-set-job-complete


Set a job to complete. Usually called from the automation that is polling the result.

Base Command

xsoar-ws-set-job-complete

Input

Argument Name Description Required
uuid Job’s uuid. Required

Context Output

There is no context output for this command.

xsoar-ws-setup-form-submission


Setup a form submission job that can take multiple values from multiple users.

Base Command

xsoar-ws-setup-form-submission

Input

Argument Name Description Required
emailaddresses Comma-separated email addresses of the recipients. Required
userstring Optional user string that can be set from the playbook. Can be used to differentiate between multiple jobs running on the same incident. Optional
htmltemplate The template to build the email content. Required
xsoarproxy Used to specify what endpoint to submit the responses. If set to false, the HTML template will have the endpoint containing the custom port. Default is true. Optional

Context Output

There is no context output for this command.

Configuration parameters

  • incidentType — Incident type
  • longRunning — Long running instance
  • longRunningPort — Server Listening Port (required)
  • xsoar-external-url — XSOAR external URL (required)

Commands (7)

  • xsoar-ws-clear-cache

    Clear the backend storage containing all session information.

  • xsoar-ws-get-action-status

    Gets the current status of an action that was setup; Used to track if the user responded to the action.

  • xsoar-ws-remove-action

    Remove a certain job from the backend.

  • xsoar-ws-set-job-complete

    Set a job to complete. Usually called from the automation that is polling the result.

  • xsoar-ws-setup-form-submission

    setup a form submission job that can take multiple values from multiple users.

  • xsoar-ws-setup-simple-action

    setup the web server to handle URL clicks for each action specified from single or multiple recipients.

  • xsoar-ws-show-cache

    Show the details of all the setup actions from the backend.

category: Utilities
provider: Palo Alto Networks
sectionorder:
- Connect
- Collect
commonfields:
  id: XSOAR-Web-Server
  version: -1
configuration:
- display: Incident type
  name: incidentType
  type: 13
  required: false
  section: Collect
- display: Long running instance
  name: longRunning
  type: 8
  required: false
  section: Connect
- additionalinfo: "Runs the service on this port from within Cortex XSOAR. Requires a unique port for each long-running integration instance. Do not use the same port for multiple instances. Note: If you click the test button more than once, a failure may occur mistakenly indicating that the port is already in use. (For Cortex XSOAR 8 and Cortex XSIAM) If you do not enter a port, an unused port for the XSOAR Web Server will automatically be generated when the instance is saved. However, if using an engine, you must enter a port."
  display: Server Listening Port
  name: longRunningPort
  required: true
  type: 0
  section: Connect
- additionalinfo: The URL on which the user should send the response to.
  display: "XSOAR external URL"
  name: xsoar-external-url
  required: true
  type: 0
  section: Connect
description: 'This is a simple web-server that as of now, supports handling configurable user responses (like Yes/No/Maybe) and data collection tasks that can be used to fetch key value pairs. What makes it different from Data collection tasks is that, the URL to perform a certain action is predictable and written to the incident context when an action is setup.This URL can be inserted to for eg: an HTML email.  User clicks are  are recorded in the integration context and can be polled by Scheduled Commands/ Generic Polling.'
display: XSOAR-Web-Server
name: XSOAR-Web-Server
script:
  commands:
  - arguments:
    - description: Comma separated possible values for each action. Mandatory for get requests.
      name: actions
      required: true
    - description: Comma separated email addresses of the recipients.
      name: emailaddresses
      required: true
    - description: User defined string that has to be set from the playbook. This is  used to differentiate between multiple jobs running on the same incident.
      name: userstring
      required: true
    - description: template to construct the html mail.
      name: htmltemplate
      required: true
    - auto: PREDEFINED
      default: true
      defaultValue: "true"
      description: Used to specify what endpoint to submit the responses. If set to false, the  html template will have the endpoint containing the custom port.
      name: xsoarproxy
      predefined:
      - "true"
      - "false"
    description: setup the web server to handle URL clicks for each action specified from single or multiple recipients.
    name: xsoar-ws-setup-simple-action
    outputs:
    - contextPath: WS-ActionDetails
      description: The current status of the action's  configuration details.
    - contextPath: WS-ActionDetails.job_uuid
      description: Subset of action details, added for ease of configuration in playbooks.
  - arguments: []
    description: Clear the backend storage containing all session information.
    name: xsoar-ws-clear-cache
  - arguments: []
    description: Show the details of all the setup actions from the backend.
    name: xsoar-ws-show-cache
  - arguments:
    - description: Job's uuid.
      name: uuid
      required: true
    description: Remove a certain job from the backend.
    name: xsoar-ws-remove-action
  - arguments:
    - description: Job's uuid.
      name: uuid
      required: true
    description: Gets the current status of an action that was setup; Used to track if the user responded to the action.
    name: xsoar-ws-get-action-status
    outputs:
    - contextPath: WS-ActionStatus
      description: The current status of the action with some configuration data. Is used for polling the status.
    - contextPath: WS-ActionStatus.link_tracker
      description: Subset of action status; tracked here to make it easier for configuring playbooks.
  - arguments:
    - description: Job's uuid.
      name: uuid
      required: true
    description: Set a job to complete. Usually called from the automation that is polling the result.
    name: xsoar-ws-set-job-complete
  - arguments:
    - description: Comma separated email addresses of the recipients.
      name: emailaddresses
      required: true
    - description: Optional user string that can be set from the playbook. Can be used to differentiate between multiple jobs running on the same incident.
      name: userstring
    - description: The template to build the email content.
      name: htmltemplate
      required: true
    - default: true
      defaultValue: "true"
      description: Used to specify what endpoint to submit the responses. If set to false, the  html template will have the endpoint containing the custom port.
      name: xsoarproxy
    description: setup a form submission job that can take multiple values from multiple users.
    name: xsoar-ws-setup-form-submission
  dockerimage: demisto/bottle:1.0.0.10133006
  longRunning: true
  longRunningPort: true
  script: ''
  subtype: python3
  type: python
fromversion: 6.5.0
tests:
- No tests (auto formatted)
triggers:
  - conditions:
      - name: engine
        operator: not_exists
      - name: isEngineGroup
        operator: not_exists
    effects:
      - name: longRunningPort
        action:
          hidden: true
          required: false