Can i somehow edit policy's xml dynamically to add several query params?

Not applicable

I've a shared flow with a Regex protection policy but as is a shared flow i'll have dynamic query params count and names depending on proxy which is being executed. for each query param i'll need to have one tag on the policy's XML like following:

<QueryParamname="a-query-param">

<Pattern>proxy.securityflow.vars.regex</Pattern>

</QueryParam>

but as query param count and name is dynamic the number of "QueryParam" tag blocks on policy's XML would be also dynamic. so: Can i somehow edit policy's xml dynamically to add several blocks? or even better is there any to reference on "name" attribute more than one query param name also reference all of them despite of its names(like regex values)?

Solved Solved
1 2 625
1 ACCEPTED SOLUTION

No, you cannot do what you describe. There may be reasonable workarounds though.

  1. If there is a limited set of valid query params, then, you could break up the existing single RegularExpressionProtection policy into several, and some of them might be wrapped in conditions. Within the shared flow, it would look like this.

      <Step>
        <Name>RegexProtection1</Name>
      </Step>
      <Step>
        <Name>RegexProtection2</Name>
        <Condition>request.queryparam.queryA != null</Condition>
      </Step>
      <Step>
        <Name>RegexProtection3</Name>
        <Condition>request.queryparam.queryB != null</Condition>
      </Step>
    	
  2. If the number of query params is totally dynamic, then you could use a JS policy to iterate through the qparams and analyze each one separately. You would use the RegExp() object within JS in a loop, instead of using the RegularExpressionProtection policy. Within the JS, just throw an error that matches the fault you'd like to catch in the proxy flow, to mimic the behavior of the RegularExpressionPolicy.

View solution in original post

2 REPLIES 2

No, you cannot do what you describe. There may be reasonable workarounds though.

  1. If there is a limited set of valid query params, then, you could break up the existing single RegularExpressionProtection policy into several, and some of them might be wrapped in conditions. Within the shared flow, it would look like this.

      <Step>
        <Name>RegexProtection1</Name>
      </Step>
      <Step>
        <Name>RegexProtection2</Name>
        <Condition>request.queryparam.queryA != null</Condition>
      </Step>
      <Step>
        <Name>RegexProtection3</Name>
        <Condition>request.queryparam.queryB != null</Condition>
      </Step>
    	
  2. If the number of query params is totally dynamic, then you could use a JS policy to iterate through the qparams and analyze each one separately. You would use the RegExp() object within JS in a loop, instead of using the RegularExpressionProtection policy. Within the JS, just throw an error that matches the fault you'd like to catch in the proxy flow, to mimic the behavior of the RegularExpressionPolicy.

Not applicable

Thank you!