Closed jpasski closed 11 years ago
We thought about that, but I'm not sure it's the right approach (as a main API). I have no problem exposing such API though if you feel like there is a need. Few things to consider:
Thing to consider: this approach also makes sense when the remediation is only to be applied at one place (most likely injection site). When we start adding filters, validators, etc. it then becomes more complex to use a unified API like that.
Anyways, I really have not much opinion on whether or not we should have this available... I guess I just don't see much interest for now. Do you have strong feelings for it?
No strong feelings. I'll fork and try something out :) Closing for now. Any future pull request can create a new issue.
As the library grows I think we'll start to have a lot of different escapers and subsequently, different method names and tag libraries. This may get confusing and also creates large nesting of methods. E.g. escaperA(escaperB(escaperC(tainted_data))). As an option I'm proposing adding a generic escaping name with a second field (first field is still the input string) that takes a List of Context enums. This would allow the author to declare the intent more succinctly to me. The underlying implementation would then just iterate over the list, calling the respective escaper method. While this adds some overhead, I think there's a benefit for some people.