auth0-deploy-cli
auth0-deploy-cli copied to clipboard
Unable to configure attackProtection setttings
Description
When trying to configure attackProtection settings via YAML:
attackProtection:
bruteForceProtection:
enabled: true
shields:
- block
- user_notification
mode: count_per_identifier
max_attempts: 6
the import command fails with:
2022-08-25T18:19:17.173Z - error: Problem running command import during stage processChanges when processing type attackProtection
2022-08-25T18:19:17.173Z - error: Cannot read property 'enabled' of undefined
The command I am running is:
import --input_file tenant.yaml --config_file ./configs/sandbox.json --secret $SANDBOX_AUTH0_CLIENT_SECRET
and the YAML shown above is added to the bottom of tenant.yaml
.
Reproduction
Detail the steps taken to reproduce this error, what was expected, and whether this issue can be reproduced consistently or if it is intermittent.
Where applicable, please include:
- Code sample to reproduce the issue
- Log files (redact/remove sensitive information)
- Application settings (redact/remove sensitive information)
- Screenshots
Environment
Please provide the following:
- Version of this library used: 7.14.3
- Version of the platform or framework used, if applicable:
- Other relevant versions (language, server software, OS, browser):
- Other modules/plugins/libraries that might be involved:
Yep, just confirmed this is an issue. It pertains to the logging function that prints a summary of the changes, it's assuming that the attack protection resource will have all three properties: suspiciousIpThrottling
, breachedPasswordDetection
and bruteForceProtection
. But to your credit, it should be flexible enough to allow you to only manage one of those sub-resources.
A inelegant workaround would be to manage the enabled
property for breachedPasswordDetection
and suspiciousIpThrottling
like so:
attackProtection:
breachedPasswordDetection:
enabled: true
suspiciousIpThrottling:
enabled: true
bruteForceProtection:
enabled: true
shields:
- block
- user_notification
mode: count_per_identifier
max_attempts: 6
This is simple enough to fix though, you can expect it to be in the next release.
Finally released with 7.15.0. Thanks for sitting tight!