-
-
Notifications
You must be signed in to change notification settings - Fork 466
Description
Thanks for kin-openapi!
We noticed some unexpected validation behavior against path parameters, and it seems to be due to how kin-openapi does routing. We allow user input which ends up in the path and wanted to apply validations to that, but things like pattern
and maxLength
were unpredictable, especially when dealing with anything besides low ASCII.
We traced the issue back to #400. That change resulted in all return parameters coming back escaped. Escaping is always tricky to keep track of, and at first we thought the issue was upstream (i.e. we were sending in escaped values). But getting back escaped values was a surprise. And passing these on to validation is problematic.
For example, say you have a path element and want to apply maxLength: 10
. Assume you're passing the results of router.FindRoute()
into ValidateRequest()
. If the path element is 🙂
, the check will fail because the test is run against %F0%9F%99%82
(length 12).
Improvement ideas
I don't think there is necessarily a bug here, especially since the router and validator are their own functions with independent contracts. But it was certainly confusing to us and a bit annoying to fix. We ended up vendoring fiber-middleware and modifying it to unescape the params maps coming back from router.FindRoute()
.
At a minimum, the documentation for these functions could probably mention this behavior.
I don't have a strong recommendation, but I wanted to get an issue in the log in case someone else is troubleshooting something similar.