Escape   in Product Names for PAYONE

[seaneble]

Good morning,

a new week, a new PAYONE 'challenge'…

I discovered that there is a problem with the current implementation for PAYONE that leads to incorrect hash calculation. We use product names with [nbsp] to prevent ugly line wraps (e.g. in front of units). These are rendered as the   character in HTML (as value of the hidden input fields). Browsers do not encode this value for some reason (!), whereas urlencode does correctly convert it to %C2%A0.
To circumvent this, I added a simple str_replace for [nbsp] to a regular whitespace.

Line 128 of Model/Payment/Payone.php:

            $arrData['de[' . $i . ']']   = specialchars(str_replace('[nbsp]', ' ', $objItem->getName() . $strOptions));

This solves it for me and PAYONE now accepts the requests. I guess one could find a cleaner solution, but I already invested two hours to find the cause.

[seaneble]

Opened chromium issue 416377.

[aschempp]

Same probably applies for PayPal and other payment methods.

[Toflar]

Can you check if this fixes your issue?

[seaneble]

I cannot imagine how this additional method call would help in any way.
As far as I understand, it transforms the Contao-internal strings like [nbsp] into their corresponding HTML entity. This method provides the ability to see such characters in plain view in the backend.

If you use this method call now, any [nbsp] in the database will be replaced for   before it goes to the template, which in turn calls the method again.

But the real problem in this case is to have the character in the hidden input fields at all. This is actually not an Isotope bug, because Chrome under Linux should encode such characters. My line of code is only a workaround until the upstream issue has been resolved (and the fix works for older Chrome versions as well).

So, if Isotope would like to support Chrome in this special situation, it would be necessary that   never makes it to the template at all. I did this by replacing it with a regular blank.

[aschempp]

Why would [nbsp] replaced in the template?

Basically, we would need to remove all HTML entities, right? Also things like ­ or &amp. What if we simply call htmlspecialchars_decode?

[aschempp]

Any feedback on this topic?

[seaneble]

Sorry for the delay. The chromium bug is very specific and Red Hat is currently investigating the source.

I don't think Isotope needs to do anything here. Escaping characters might be a workaround, but investing time is not appropriate seeing the nature of the chromium bug.

[seaneble]

Bad idea to close this issue. There seem to be other weird constellations in which having entities in the request to PAYONE is not a good idea.

Unfortunately, Yanicks line

specialchars(
    \String::restoreBasicEntities($objItem->getName() . $strOptions),
    true
)

still leaves all the entities like   intact. I don't know about all the contao functions, but could we introduce some function call that actually replaces entities with harmless characters?

For now, I have included my str_replace again because that's the only way the customer can use the credit card integration at the moment.

[aschempp]

Did you find any other solution than str_replace?

[seaneble]

Nope, it helps, so I closed our internal ticket. If you choose to integrate the same line or a similar functionality with a more complicated function call, that would be fine. If you opt to change nothing, we would have to patch Isotope after each update of the file. Either way would work.

[aschempp]

The best possible solution is likely to remove all HTML stuff from forms sent to the payment providers. This does not only affect PayOne but also others like PayPal.
Because this will lead to a "different system behavior", we decided to do this in the next minor release.

[pxpl]

I have similar problems because of '&' and '(' and ')' in the product name. (Error message 'Hashwert nicht korrekt').
Therefore I changed
$arrData['de[' . $i . ']'] = specialchars( \StringUtil::restoreBasicEntities($objItem->getName() . $strConfig), true );
to
$strName = \StringUtil::restoreBasicEntities($objItem->getName() . $strConfig);
$arrData['de[' . $i . ']'] = html_entity_decode($strName);

and this works for me, but I guess there are better solutions?

[aschempp]

@qzminski please prepare a PR to fix this. Maybe the cleaning method should go in Haste StringUtils? Or is there an existing method to remove all special stuff and HTML markup?

[qzminski]

See #1687. Can anyone test it please?

[seaneble]

Yeah! That one works (for my problem, I don't know about @pxpl).

I would suggest moving the method to some more generic place, so other payment methods etc. can use it as well. Thanks, @qzminski!

[qzminski]

I also wonder, maybe we could only do:

1. str_replace() to replace   for the value in general
2. htmlspecialchars(\StringUtil::restoreBasicEntities(), true) for the value in general
3. html_entity_decode() for the value but only for hash generation

That would result in properly encoded field value in HTML and the hash generated with decoded entities (just like does Payone probably).

[aschempp]

We basically need to convert every value to plain text, right?

[pxpl]

#1687 works for me, too!

[aschempp]

Closed in favor of #1687

[aschempp]

Should be finally fixed in 8410fd4