new feature: Test Forbidden 403

[Leemur89]

Hello, Similar to the keyword Test Unauthorized that sends the request without authorization header and expects a 401 error, it would be interesting to have a keyword Test Forbidden for which we provide (either with a new param in lib import or in keyword argument - or both) a security header, and expect a 403 response

Btw the readme states in the limitation "only simple 401 / 403 validation", but actually only 401 is supported at the moment. That feature request would implement the 403 validation.

Thanks

[Leemur89]

For information current workaround I'm using is the expect error:

    Run Keyword And Expect Error
    ...    Response status_code 403 was not ???
    ...    Test Endpoint
    ...    path=${path}
    ...    method=${method}
    ...    status_code=${status_code}

[robinmackaij]

I've considered security-related validations in the past and, where applicable, solved it by using separate suites where the security-related parameters were generated such that, for the included endpoints, a 403 would be returned. These suites would only test for 403 (ignore all other response using ignored_responses).

The issue with Forbidden is that it's a status code that's also quite commonly used instead of 422 when operations are denied due to the state of related resources.

Simple 403 scenarios are supported for those cases where a security_token or auth instance can be used. This is, however, insufficient for role-based testing of an API.

[Leemur89]

Yes I've tried using a specific security_token, but the problem is that the generator from data_mapping complains that it is not configured to prepare data for 403 errors, or maybe am I setting it wrong? Because the data_mapping would be exactly the same for 200 and for 403, the only difference is the security_token I use when importing the lib

[robinmackaij]

The mappings are not designed to handle security-based statuses, hence my suggestion to perform the security-related 403 checks to a separate suite. In that suite, the Test Endpoint would be wrapped by Run Keyword And Expect Error and the error you'd expect would be the "Forbidden" message.

[Leemur89]

This is actually what I'm doing (expected error Response status_code 403 was not ??? and not Forbidden), but this is logging an error, which in the end brings a log of red in my final report

(errors are brought forward at the beginning of the report)

there are 2 things in robot: the actual failure (Response status_code 403 was not 200) and the error (Forbidden: response contains no message or detail.) I'm expecting the failure and my test is green, but still the library is logging an error

[robinmackaij]

You're right, we'll need a separate keyword for this. I'll take a look at adding a keyword similar to the 401 keyword. Due to the nature of the check, the privilege-based validations will need to go into a separate suite due to the 403 errors that are data-based.

[Leemur89]

@robinmackaij wow, thanks for your incredibly fast reaction!