-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SOAR-17874] Mimecast #2897
[SOAR-17874] Mimecast #2897
Conversation
if rate_limited > now: | ||
log_msg += "Still within rate limiting period, skipping task execution..." | ||
self.logger.info(log_msg) | ||
return [], state, False, 200, None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only thing about this is that the customer won't have any idea they're rate limited 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unless we put it the task into error state, we currently have no way to display any task info back to idr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we return a recoverable error message/status code, these should get bubbled in the 'warning' text colour and the integration is still scheduled for the next run
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mIght be a PM question to confirm as we haven't done this before, but I agree with Nathanael it would be good to let the customer know they're being rate limited. If we return status code 429, and then the error with cause with something like 'Rate limiting enforced from Mimecast' would show on the UI but let the integration be scheduled on the 5 minute interval, and it could prevent tickets raised for why no data has been pulled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only thing is that if we put the task into an error state we won't store the fact that we're rate limited 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated this now. The state should include a new rate limit value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on chat with @nmccullagh-r7 . Update plugin to return 200 on first go, immediately retry and return the new 429. This way the state will be updated to include the retry limit timestamp.
30b0cc2
to
196d039
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current logic looks good, but I'm just wondering if we could improve it a slightly so we base the time on what Mimecast returns and surface this to the customer?
plugins/mimecast/komand_mimecast/tasks/monitor_siem_logs/task.py
Outdated
Show resolved
Hide resolved
if rate_limited > now: | ||
log_msg += "Still within rate limiting period, skipping task execution..." | ||
self.logger.info(log_msg) | ||
return [], state, False, 200, None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mIght be a PM question to confirm as we haven't done this before, but I agree with Nathanael it would be good to let the customer know they're being rate limited. If we return status code 429, and then the error with cause with something like 'Rate limiting enforced from Mimecast' would show on the UI but let the integration be scheduled on the 5 minute interval, and it could prevent tickets raised for why no data has been pulled?
86876a9
to
9cb0c4a
Compare
196d039
to
87a4595
Compare
Updated error message in PR. Agreed with PM that we can return a 429 for rate limiting errors. |
e7f10ec
to
2e967fc
Compare
6899131
to
410384a
Compare
* Add 401 exception handling * Fix it up * Rename response to new response
5869c5d
to
cc8f87d
Compare
96bdbd3
to
a96233e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Palo alto retry creds 401 (#2826) * Add 401 exception handling * Fix it up * Rename response to new response * Add 429 handler to task | update sdk | add unit test * Update requirements werkzeug * Update rate limit error * Updare bandit * Update error logging * Update value returned by check rate limit status code * Update SDK * Update return 200 first 429 * Update has_more_pages * Update task.py --------- Co-authored-by: Conor <[email protected]>
* Palo alto retry creds 401 (#2826) * Add 401 exception handling * Fix it up * Rename response to new response * Add 429 handler to task | update sdk | add unit test * Update requirements werkzeug * Update rate limit error * Updare bandit * Update error logging * Update value returned by check rate limit status code * Update SDK * Update return 200 first 429 * Update has_more_pages * Update task.py --------- Co-authored-by: Conor <[email protected]>
* Palo alto retry creds 401 (#2826) * Add 401 exception handling * Fix it up * Rename response to new response * Add 429 handler to task | update sdk | add unit test * Update requirements werkzeug * Update rate limit error * Updare bandit * Update error logging * Update value returned by check rate limit status code * Update SDK * Update return 200 first 429 * Update has_more_pages * Update task.py --------- Co-authored-by: Conor <[email protected]>
* Palo alto retry creds 401 (#2826) * Add 401 exception handling * Fix it up * Rename response to new response * Add 429 handler to task | update sdk | add unit test * Update requirements werkzeug * Update rate limit error * Updare bandit * Update error logging * Update value returned by check rate limit status code * Update SDK * Update return 200 first 429 * Update has_more_pages * Update task.py --------- Co-authored-by: Conor <[email protected]>
Proposed Changes
Description
Describe the proposed changes:
PR Requirements
Developers, verify you have completed the following items by checking them off:
Testing
Unit Tests
Review our documentation on generating and writing plugin unit tests
In-Product Tests
If you are an InsightConnect customer or have access to an InsightConnect instance, the following in-product tests should be done:
Style
Review the style guide
USER nobody
in theDockerfile
when possiblerapid7/insightconnect-python-3-38-slim-plugin:{sdk-version-num}
andrapid7/insightconnect-python-3-38-plugin:{sdk-version-num}
insight-plugin validate
which callsicon_validate
to linthelp.md
Functional Checklist
tests/
directory created withinsight-plugin samples
tests/$action_bad.json
insight-plugin run -T tests/example.json --debug --jq
insight-plugin run -T all --debug --jq
(use PR format at end)insight-plugin run -R tests/example.json --debug --jq
insight-plugin run --debug --jq
(use PR format at end)Assessment
You must validate your work to reviewers:
insight-plugin validate
and make sure everything passesinsight-plugin run -A
. For single action validation:insight-plugin run tests/{file}.json -A
insight-plugin ... | pbcopy
) and paste the output in a new post on this PR