patch for issue #47, add in_string

[mirkogleibe]

Contao sometimes renders < as < in Frontend, so I added a htmlDecode function to prevent < from causing js errors. Cause I needed it, i also added a in_string function for finding strings in fields. In this case I wanted to get parts of a hidden field manipulated via js. I used the includes function not usable with IE in any version, but there is a polyfill.

[mirkogleibe]

Just named it in_string. str_contains() would be the php 8 version. There is no other function just returning true:false I think. For php 7 down there are some ployfills in the php manual.

[aschempp]

So it should be called str_contains and we need to provide a polyfill?

[mirkogleibe]

Even realized str_contains() polyfill is part of symfony/polyfill-php80 as part of symfony/http-kernel ^4.4 wich is required by contao 4.9*

public static function str_contains(string $haystack, string $needle): bool
{
  return '' === $needle || false !== strpos($haystack, $needle);
}

[aschempp]

Great find, thanks! I didn't even know about str_contains 😆

Contao aometimes renders < as < in Frontend

I would prefer to know why this happens. We might need to allow all HTML in the input field or thelike? Did you find a way to reproduce the problem?

Did you find a reason for this as well?

[mirkogleibe]

I think there could be two reasons.

1. json_encode without flags will encode some characters not the way expected
2. dca decodeEntities->true will only decode html tags, not special characters.

by the way are there some changes with form field handling since ^4.9.18 To prevent XSS all fields are encoded more strictly. Something like comparison operators cause massive headache at the moment. ;)

[contaoacademy]

Ich bin ebenfalls über das Problem gestolpert. Wäre es möglich das Patch kurzfristig zu übernehmen?

[aschempp]

@contaoacademy welches Problem?

Regarding the HTML decoding, this looks suspicious for XSS injection to me. Maybe @ausi can quickly check this? 🙃

[contaoacademy]

Ich habe eine Abfrage mit einem Vergleichsoperator

$foo<10

Im Quellcode wird die Bedingung leider so ausgegeben:

return (values.foo[lt]10)

Mit == und > gibt es kein Problem. Das entsteht nur bei <

[doishub]

Regarding the HTML decoding, this looks suspicious for XSS injection to me.

We had the same problem in one of our extensions. Perhaps the consideration here would also be to use the ExpressionLanguage component of Symfony to get more control over allowed evaluations.

To add an in_string method needs its own method. For native PHP functions you can use e.g.

ExpressionFunction::fromPhp('str_contains');

Maybe this will help you. 😉

[aschempp]

Version 3.0.0 should allow for this 😎