У нас есть API, настроенный в API Manager, с некоторыми продуктами и политиками. Одна из политик пытается гарантировать, что для некоторых параметров запроса всегда установлено определенное значение.
<set-query-parameter name = "myParameter" exists-action = "override">
<value>myFixedValue</value>
</set-query-parameter>
Это работает нормально, пока кто-нибудь не добавит один и тот же параметр с другим регистром, например. MyParameter или mYpAraMeTeR, в этом случае политика set-query-parameter игнорируется, поскольку она чувствительна к регистру.
Есть ли способ обеспечить правильное применение этой политики без учета регистра?
После некоторых поисков я нашел полис validate-parameters, который, как я надеялся, поможет, но пока не нашел волшебного сочетания свойств.
<validate-parameters specified-parameter-action = "ignore" unspecified-parameter-action = "prevent" errors-variable-name = "validationErrors">
<headers specified-parameter-action = "ignore" unspecified-parameter-action = "ignore"/>
<query specified-parameter-action = "ignore" unspecified-parameter-action = "prevent">
<parameter name = "myParameter" action = "ignore" />
</query>
<path specified-parameter-action = "ignore"/>
</validate-parameters>
Я надеялся, что это просто передаст все предоставленные заголовки и пути, но ограничит разрешенные параметры запроса только myParameter
Надеюсь, кто-то с немного большим знанием APIM сможет мне помочь :)


Похоже, validate-parameters также чувствителен к регистру.
Правильное определение политики будет таким:
<policies>
<inbound>
<base />
<validate-parameters specified-parameter-action = "ignore" unspecified-parameter-action = "prevent" errors-variable-name = "requestParametersValidation">
<headers specified-parameter-action = "ignore" unspecified-parameter-action = "ignore" />
<query specified-parameter-action = "ignore" unspecified-parameter-action = "prevent">
<parameter name = "myParameter" action = "ignore" />
</query>
</validate-parameters>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
Но это выдаст вам ошибку, если вы передадите любое другое значение, кроме параметра myParameter. Это не будет работать для значений регистра myParameter.


Итак, в качестве альтернативы я использую приведенную ниже политику, которая работает только для myParameter, но не для любой другой комбинации параметра myParameter.
<policies>
<inbound>
<base />
<choose>
<when condition = "@(context.Request.Url.Query.TryGetValue("myParameter", out var value) && value.Any(v => string.Equals(v, "myFixedValue", StringComparison.OrdinalIgnoreCase)))" />
<otherwise>
<return-response>
<set-status code = "400" reason = "Bad Request" />
<set-header name = "Content-Type" exists-action = "override">
<value>text/plain</value>
</set-header>
<set-body>@("Only the 'myParameter' query parameter is allowed.")</set-body>
</return-response>
</otherwise>
</choose>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
Выход-




След-

После некоторого обсуждения в нашей команде выяснилось, что для этого продукта пользователям никогда не разрешалось указывать собственное значение для
myParameter, поэтому на данный момент мы остановились на следующем решении:<when condition='@(context.Request.Url.Query.Keys.Contains("organisatieonderdeelIds", StringComparer.InvariantCultureIgnoreCase) == true)'> <return-response> <set-status code = "400" reason = "Bad request - unsupported parameter provided"/> </return-response></when>