crimson-falcon 1.0.1 → 1.1.0

data/lib/crimson-falcon/api/alerts.rb

@@ -465,8 +465,8 @@ module Falcon
       return data, status_code, headers
     end
 
-    # Retrieves all Alerts that match a particular FQL filter.
-    # @param body [DetectsapiPostCombinedAlertsV1RequestSwagger] `after` - Token used to access the next page. The `after` token will be populated only when the service expects more results expected on the next page.  Once you reach the last page (which usually has less than `limit` results), the `after` token will not be returned anymore.   The best way to retrieve all the results is to paginate them till you get to the last page where the `after` token blank.   This value is highly dependant on the `sort` parameter, so if you plan to change the sort order, you will have to re-start your search from the first page (without `after` parameter).  `filter` - Filter Alerts using a query in Falcon Query Language (FQL).Filter fields can be any keyword field that is part of #domain.Alert  An asterisk wildcard `*` includes all results.   Empty value means to not filter on anything. Most commonly used filter fields that supports exact match: cid, id, aggregate_id, product, type, pattern_id, platform ... Most commonly used filter fields that supports wildcard (*): assigned_to_name, assigned_to_uuid, tactic_id, technique ... Most commonly filter fields that supports range comparisons (>, <, >=, <=): severity, created_timestamp, timestamp, updated_timestamp... All filter fields and operations support negation (!).   The full list of valid filter options is extensive. Review it in our [documentation inside the Falcon console](https://falcon.crowdstrike.com/documentation/45/falcon-query-language-fql).  `limit` - The maximum number of detections to return in this response (default: 100; max: 1000). Use this parameter together with the `after` parameter to manage pagination of the results.  `sort` - Sort parameter takes the form of `<field|direction>`.   The sorting fields can be any keyword field that is part of #domain.Alert except for the text based fields. Most commonly used fields for sorting are: timestamp, created_timestamp, updated_timestamp, status, aggregate_id, assigned_to_name, assigned_to_uid, assigned_to_uuid, tactic_id, tactic, technique, technique_id, pattern_id or product.  By default all the results are sorted by the `created_timestamp` field in the descending order.  **Important:** The pagination is done on live data in the order defined by the `sort` field parameter (default: `created_timestamp|desc`), so if you want to avoid inconsistent results where the same record might appear on multiple pages (or none), sort only on the fields that do not change over time (e.g. created_timestamp, composite_id, ...).
+    # Retrieves all Alerts that match a particular FQL filter. This API is intended for retrieval of large amounts of Alerts(>10k) using a pagination based on a `after` token. If you need to use `offset` pagination, consider using GET /alerts/queries/alerts/* and POST /alerts/entities/alerts/* APIs.
+    # @param body [DetectsapiPostCombinedAlertsV1RequestSwagger] `after` - The `after` token is used for pagination of results. The `after` token is present when more results are available on the next page. To retrieve all Alerts:    - Use the `after` token in subsequent requests to fetch the next page.   - Continue this process until you reach a page without an `after` token, indicating the last page.  This value is highly dependant on the `sort` parameter, so if you plan to change the sort order, you will have to re-start your search from the first page (without `after` parameter).  `filter` - Filter Alerts using a query in Falcon Query Language (FQL).Filter fields can be any keyword field that is part of #domain.Alert  An asterisk wildcard `*` includes all results.   Empty value means to not filter on anything. Most commonly used filter fields that supports exact match: cid, id, aggregate_id, product, type, pattern_id, platform ... Most commonly used filter fields that supports wildcard (*): assigned_to_name, assigned_to_uuid, tactic_id, technique ... Most commonly filter fields that supports range comparisons (>, <, >=, <=): severity, created_timestamp, timestamp, updated_timestamp... All filter fields and operations support negation (!).   The full list of valid filter options is extensive. Review it in our [documentation inside the Falcon console](https://falcon.crowdstrike.com/documentation/45/falcon-query-language-fql).  `limit` - The maximum number of detections to return in this response (default: 100; max: 1000). Use this parameter together with the `after` parameter to manage pagination of the results.  `sort` - Sort parameter takes the form of `<field|direction>`.   The sorting fields can be any keyword field that is part of #domain.Alert except for the text based fields. Most commonly used fields for sorting are: timestamp, created_timestamp, updated_timestamp, status, aggregate_id, assigned_to_name, assigned_to_uid, assigned_to_uuid, tactic_id, tactic, technique, technique_id, pattern_id or product.  By default all the results are sorted by the `created_timestamp` field in the descending order.  **Important:** The pagination is done on live data in the order defined by the `sort` field parameter (default: `created_timestamp|desc`), so if you want to avoid inconsistent results where the same record might appear on multiple pages (or none), sort only on the fields that do not change over time (e.g. created_timestamp, composite_id, ...).
     # @param [Hash] opts the optional parameters
     # @return [DetectsapiPostCombinedAlertsV1ResponseSwagger]
     def post_combined_alerts_v1(body, opts = {})
@@ -474,8 +474,8 @@ module Falcon
       data
     end
 
-    # Retrieves all Alerts that match a particular FQL filter.
-    # @param body [DetectsapiPostCombinedAlertsV1RequestSwagger] `after` - Token used to access the next page. The `after` token will be populated only when the service expects more results expected on the next page.  Once you reach the last page (which usually has less than `limit` results), the `after` token will not be returned anymore.   The best way to retrieve all the results is to paginate them till you get to the last page where the `after` token blank.   This value is highly dependant on the `sort` parameter, so if you plan to change the sort order, you will have to re-start your search from the first page (without `after` parameter).  `filter` - Filter Alerts using a query in Falcon Query Language (FQL).Filter fields can be any keyword field that is part of #domain.Alert  An asterisk wildcard `*` includes all results.   Empty value means to not filter on anything. Most commonly used filter fields that supports exact match: cid, id, aggregate_id, product, type, pattern_id, platform ... Most commonly used filter fields that supports wildcard (*): assigned_to_name, assigned_to_uuid, tactic_id, technique ... Most commonly filter fields that supports range comparisons (>, <, >=, <=): severity, created_timestamp, timestamp, updated_timestamp... All filter fields and operations support negation (!).   The full list of valid filter options is extensive. Review it in our [documentation inside the Falcon console](https://falcon.crowdstrike.com/documentation/45/falcon-query-language-fql).  `limit` - The maximum number of detections to return in this response (default: 100; max: 1000). Use this parameter together with the `after` parameter to manage pagination of the results.  `sort` - Sort parameter takes the form of `<field|direction>`.   The sorting fields can be any keyword field that is part of #domain.Alert except for the text based fields. Most commonly used fields for sorting are: timestamp, created_timestamp, updated_timestamp, status, aggregate_id, assigned_to_name, assigned_to_uid, assigned_to_uuid, tactic_id, tactic, technique, technique_id, pattern_id or product.  By default all the results are sorted by the `created_timestamp` field in the descending order.  **Important:** The pagination is done on live data in the order defined by the `sort` field parameter (default: `created_timestamp|desc`), so if you want to avoid inconsistent results where the same record might appear on multiple pages (or none), sort only on the fields that do not change over time (e.g. created_timestamp, composite_id, ...).
+    # Retrieves all Alerts that match a particular FQL filter. This API is intended for retrieval of large amounts of Alerts(>10k) using a pagination based on a `after` token. If you need to use `offset` pagination, consider using GET /alerts/queries/alerts/* and POST /alerts/entities/alerts/* APIs.
+    # @param body [DetectsapiPostCombinedAlertsV1RequestSwagger] `after` - The `after` token is used for pagination of results. The `after` token is present when more results are available on the next page. To retrieve all Alerts:    - Use the `after` token in subsequent requests to fetch the next page.   - Continue this process until you reach a page without an `after` token, indicating the last page.  This value is highly dependant on the `sort` parameter, so if you plan to change the sort order, you will have to re-start your search from the first page (without `after` parameter).  `filter` - Filter Alerts using a query in Falcon Query Language (FQL).Filter fields can be any keyword field that is part of #domain.Alert  An asterisk wildcard `*` includes all results.   Empty value means to not filter on anything. Most commonly used filter fields that supports exact match: cid, id, aggregate_id, product, type, pattern_id, platform ... Most commonly used filter fields that supports wildcard (*): assigned_to_name, assigned_to_uuid, tactic_id, technique ... Most commonly filter fields that supports range comparisons (>, <, >=, <=): severity, created_timestamp, timestamp, updated_timestamp... All filter fields and operations support negation (!).   The full list of valid filter options is extensive. Review it in our [documentation inside the Falcon console](https://falcon.crowdstrike.com/documentation/45/falcon-query-language-fql).  `limit` - The maximum number of detections to return in this response (default: 100; max: 1000). Use this parameter together with the `after` parameter to manage pagination of the results.  `sort` - Sort parameter takes the form of `<field|direction>`.   The sorting fields can be any keyword field that is part of #domain.Alert except for the text based fields. Most commonly used fields for sorting are: timestamp, created_timestamp, updated_timestamp, status, aggregate_id, assigned_to_name, assigned_to_uid, assigned_to_uuid, tactic_id, tactic, technique, technique_id, pattern_id or product.  By default all the results are sorted by the `created_timestamp` field in the descending order.  **Important:** The pagination is done on live data in the order defined by the `sort` field parameter (default: `created_timestamp|desc`), so if you want to avoid inconsistent results where the same record might appear on multiple pages (or none), sort only on the fields that do not change over time (e.g. created_timestamp, composite_id, ...).
     # @param [Hash] opts the optional parameters
     # @return [Array<(DetectsapiPostCombinedAlertsV1ResponseSwagger, Integer, Hash)>] DetectsapiPostCombinedAlertsV1ResponseSwagger data, response status code and response headers
     def post_combined_alerts_v1_with_http_info(body, opts = {})

data/lib/crimson-falcon/api/api_integrations.rb

@@ -133,7 +133,7 @@ module Falcon
       # header parameters
       header_params = opts[:header_params] || {}
       # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json'])
+      header_params['Accept'] = @api_client.select_header_accept(['*/*', 'application/json'])
       # HTTP header 'Content-Type'
       content_type = @api_client.select_header_content_type(['application/json'])
       if !content_type.nil?