az webapp config access-restriction remove fails if an existing rule has empty name

[Arthyon]

Describe the bug

Command Name
az webapp config access-restriction remove

Errors:

'NoneType' object has no attribute 'lower'
Traceback (most recent call last):
Temp\pip-install-p8t_6awn\knack\knack\cli.py, ln 206, in invoke
azure\cli\core\commands\__init__.py, ln 603, in execute
azure\cli\core\commands\__init__.py, ln 661, in _run_jobs_serially
azure\cli\core\commands\__init__.py, ln 654, in _run_job
Local\Temp\pip-install-p8t_6awn\six\six.py, ln 693, in reraise
azure\cli\core\commands\__init__.py, ln 631, in _run_job
azure\cli\core\commands\__init__.py, ln 306, in __call__
azure-cli-core\azure\cli\core\__init__.py, ln 485, in default_command_handler
azure\cli\command_modules\appservice\access_restrictions.py, ln 94, in remove_webapp_access_restriction
AttributeError: 'NoneType' object has no attribute 'lower'

To Reproduce:

• Ensure there is an existing restriction with an empty name present in the web app
• az webapp config access-restriction remove --rule-name {} -g {} -n {}

Expected Behavior

An updated list of rules should be returned.

Environment Summary

Windows-10-10.0.16299-SP0
Python 3.6.6
Shell: powershell.exe

azure-cli 2.0.75

Additional Context

It seems the error is this line: https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/azure/cli/command_modules/appservice/access_restrictions.py#L94

It does not expect rule.name to be None, even though it is possible to create rules without a name both in the GUI and previous ARM-versions (e.g. web sites (2016-08-01))

[Juliehzl]

cc @AzureAppServiceCLI @antcp

[panchagnula]

@madsd can you take a look at this? Thank you.

[madsd]

@panchagnula sure, I will look at it. The access restrictions has a very loose schema, and just fixing the check for an empty name will not allow you to remove a rule by empty name. So I will need to include the option of removing by subnet/ipaddress.

@Arthyon, thanks for bringing this to our attention. This was not a use case I had tested for. We will make the necessary changes to support this scenario.

[Arthyon]

No problem. Thank you for responding :)

[madsd]

@Arthyon the issue has been fixed now and will be rolled out as part of 2.0.78.

[Arthyon]

Thank you Mads!

I'll close this issue now. The fix seems solid :)