Description
Invalid validation rule for security group
We have a validation rule in place that checks for the correct name of a security group. It does not allow consecutive special characters in a name that is actually valid:
cls.pydantic_validator.validate_python(\npydantic_core.pydantic_core.ValidationError: 1 validation error for SecurityGroup\nname\n
Value error, must validate the regular expression /^[A-Za-z0-9]+((-||\s|\.)[A-Za-z0-9]+)*$/ [type=value_error, input_value='Nagios Monitoring - NRPE', input_type=str]
The problem is, that a space, dash and another space in a row are correct, but maybe two spaces are not. Either the regex needs to be more specific or is should be deleted.
Steps to reproduce
The error is in the class iaas/models/security_group.py
@field_validator("name")
def name_validate_regular_expression(cls, value):
"""Validates the regular expression"""
if not re.match(r"^[A-Za-z0-9]+((-|_|\s|\.)[A-Za-z0-9]+)*$", value):
raise ValueError(r"must validate the regular expression /^[A-Za-z0-9]+((-|_|\s|\.)[A-Za-z0-9]+)*$/")
return valuethe security groups cannot even be loaded:
def __get_security_groups(self, client: DefaultApi, uuid: UUID) -> List[StackitSecurityGroup]:
security_groups = client.list_security_groups(uuid)Actual behavior
Raises an exception on valid security names
Expected behavior
Raise only an exception on invalid security group name
Environment
- OS: Mac
- Python version (see
python --version):Python 3.9.4 - Version of the Python STACKIT SDK: 4.5.0
Unfortunately I could not find the check Openstack is implementing in its code and validation ...
Maybe it is also not in the responsibility of this class to check weather the name complies with a certain pattern as the Openstack Neutron server will raise a 4xx error when the name is not correct (e.g., too long, already taken, etc) in any case. Maybe we want to rely on what Openstack says to the name (or any other field, or even on any other resource). Maybe we will not be able to keep up with changes on the server side.
Ups, now I see this bug: #790
Same problem, different Openstack resource
Again, maybe not the responsibility of this lib to check for the validity of the names, esp. not when reading only the resources