On Tue, 22 Jun 2021 at 09:59, Stephen Reay <php-li...@koalephant.com> wrote:
> So I just want to make sure I understand the progression on this so far. > It started out with people wanting a way to check that a string was a > literal string, in code somewhere, and does not come from user input. Ok > makes sense. The name makes sense too. > The primary reason was never just to define literal strings, the intention has always been to create a practical, implementable solution to address the issue of Injection Vulnerabilities (SQl/HTML/CLI/etc). The name `is_literal()` has always just been a placeholder, it came up when I first started looking at this problem because that was the most obvious thing I knew we could anchor around. (Unfortunately I think it was easy to make assumptions based solely on that name, rather than focussing on the issue it is meant to address). So, we cannot look for literals only - while it was part of the solution, it was very much incomplete. Bearing in mind, there is considerable amount of existing code and tutorials out there which include integers in their SQL/HTML/CLI/etc, and they are perfectly safe in doing so. Making a solution which does not support integers is not going to be adopted/used because the task of rewriting and changing everything, for no benefit, will not be considered by developers. Likewise, a lot of code already builds SQL/HTML/CLI/etc strings via concatenation and sprintf(), and forcing everyone to use a query builder is likely to cause most people to not even consider using this. It's all well thinking of one thing that might theoretically/idealistically solve the issue, but it also needs to have a plan on how this will be practically implemented and used by developers (which this has done). Craig
