Parameter customization #380
Description
In versions < 8 it was possible to customize the parameter match using a regex. For example, :param(a|b|c). While this is immensely helpful for end users, it created a security issue if the user manages to generate a vulnerable regex. This is incredibly hard for users to avoid because the individual parameters may not be vulnerable to ReDoS but when combined together it generates something unsafe.
This issue is to bring back the same parameter match override (the part after :param between parens) but doesn't re-introduce a vulnerability. Two approaches I can think of are:
- Whitelist a subset of regex features that can be safely combined
- Add a DSL that translates into a safe regex
I think the best path forward is likely a regex-like DSL, given that regex itself can be different depending on the flags used, and there's no control over the flags in this library (e.g. unicode support). For majority of people, it would just be regex anyway.
An additional benefit of having a little more control over the customization instead of directly passing through a regex is also support for encodePath. In older versions, there was a disconnect because the path itself was encoded for matches but the regex was not, so something trivial like /^ and /:param(^) resulted in different regexes.