v0.5.0
FEATURES:
- custom response definition: Previously, the response that was given in case the request was accepted or denied was fixed, now you can define it in both cases in the response field of the configuration.
- custom request auth requirement list: Previously the configuration only had one authorization method, so the condition for the request to be accepted only depended on that method, now you can define a list of requirements, each requirement has a list of authorizations, the request must pass all the defined requirements to be accepted, and to pass a requirement it must pass all the authorizations on its list or just one depending on the type of requirement (all|any).
- ip list authorization: Previously you could only check if the value of the defined parameter was a valid hmac, now you can also check if the value is an IP belonging to the CIDR you define, and if it is a list you can remove all the IPs that belong to the list of trusted networks you define until you only have the IP to check left, you can also make it behave in reverse.
BREAKING CHANGES:
- upgrade to v1alpha2 api:
- list of authorizations: Previously, the authorization field existed, it was deleted and now the authorizations field was added. This field is a list that contains objects of the authorization type with the same fields as before.
- hmac field now is part of authorization objects: Previously the hmac field was a root field of the configuration, now it is part of the authorization objects.
- the response statusCode field must be defined
- the requestAuthRequirements field must have at least 1 requirement defined, and the requirements must have at least 1 authorization name listed