Specifying unique parameters

[microsoft]

Specifying unique parameters

[rifiles]

Hi Joshua,

To answer your first question about unique resources, I believe this can be solved using the create-once feature. This feature allows you to specify an endpoint in the settings file whose resource(s) will only be created once at the start of the fuzzing run and then deleted at the end of the run.

To do this, include the endpoint in the "per_resource_settings" dict in the settings file and add "create_once": 1 as one of that endpoint's options, like so:

"per_resource_settings": {
    "/your/endpoint/resourcetobecreatedonce" : {
        "create_once": 1
    }
}

If the producer-consumer dependencies for this request are correct in the grammar, the requests that consume the singly-created resource will be fuzzed using that single resource as a static value, while the create-once resource itself will not be.

[marina-p]

Hello @JoshuaEN,

One quick pointer before I've had a chance to look at your example project.

1. If by "unique" you mean one specific "magic value" that should always be used, the way to do this is to specify a restler_custom_payload with the exact path to the parameter or property. What didn't work when you tried adding restler_custom_payload?

2. We don't support equality constraints yet. If (1) above is just one static value, you could simply include both properties in restler_custom_payload and specify the same value.

[JoshuaEN]

Hi Richard,

Thanks for the suggestion. After some testing, using create_once appears to avoid generating HTTP errors, however it also appears to exclude the resource creation and deletion endpoint from the fuzzing. This makes sense, but ideally it would be possible to fuzz endpoints in the future even if they require unique values as parameters.

That said, this is a good work around. Thanks again!

[JoshuaEN]

Hello @marina-p,

Thanks for looking into this. Regarding (1), unique in that the parameter (e.g. id) needs to be unique across instances of that resource. A primary key in a database table effectively.

Using the restler_custom_payload worked as expected (in that it used the custom payload value instead of the normal fuzzing value), but the REST API requires the parameter is unique across all of that resource.

---

I think what I want is a way to specify the provider of a parameter as a random generator, maybe like how UUID suffix properties are currently represented in dependencies.json for PUT producers?

{
          "producer_endpoint": "",
          "producer_method": "",
          "producer_resource_name": "restler_custom_payload_uuid_suffix__testId",
          "consumer_param": "testId"
}

(I tried to add a custom annotation in this style, but it didn't appear to work)

[marina-p]

After further investigation -

1. Re: A way to specify which parameter names for a request (or globally) should be unique

This does not work due to a bug, and we will fix it shortly. This should work by providing the suffix values the same as custom payload is provided, for example:

  "restler_custom_payload_uuid4_suffix": {
      "resourceId": "resourceprefix",
      "/resource/id": "resourceprefix"
    }

This will produce the following grammar:

    primitives.restler_custom_payload_uuid4_suffix("resourceId"),
    primitives.restler_static_string(" HTTP/1.1\r\n"),
    ...
    primitives.restler_static_string("{"),
    primitives.restler_static_string("""
    "resource":
        {
            "id":"""),
    primitives.restler_custom_payload_uuid4_suffix("/resource/id"),
    primitives.restler_static_string(""",
...

RE: And for those unique parameters, which ones within a request should match (have the same unique value)

This is a new feature needed for cases when the parameters aren't named the same, so a global replacement is not possible (such as in the case above, where "resourceId" and "/resource/id" will get different suffixes in the same request). The equality constraint will most likely be supported via an annotation. Unfortunately, for now the only workaround is to modify the grammar.json/grammar.py.

[JoshuaEN]

Thank you looking into this further and for the detailed response! It is very helpful to know both of these cases are planned to be supported in the future.