Anyone else having issues with the summary redirect to the place order step in the checkout? Especia

Alberto Reyer

Anyone else having issues with the summary redirect to the place order step in the checkout? Especially in chrome and edge.

We have seen some strange behavior and could track it down to the browser denying access to forms that do a redirect afterwards, as done by the summary step in the checkout.

This is most likely caused by https://github.com/spryker/application/commit/92aaf096966a0724e726c6744533f900a924316d, where form-action: 'self' was added, among other directives, to the Content-Security-Policy Header.
There is a year old discussion, which still has no resolution, by the W3C (https://github.com/w3c/webappsec-csp/issues/8) about chrome and probably all other webkit based browsers, do implement the behavior a little bit strange, blocking all form that redirect after sending the form data.
MDN has a warning about this behavior: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/form-action

@valerii.trots / @florian.scholz Can you confirm that the checkout is broken in the demoshop as well? (https://github.com/spryker/application/releases/tag/3.28.1 is causing the issue).
If so I assume this needs a hotfix as it will impact all customers who do the patch update and might brake their checkouts as well. I'm also questioning why changing a security header, which has significant impact on applications, is a patch and not at least a minor.

Alberto Reyer

Can be fixed by removing the form-action: 'self' from the CSP header:

<?php

namespace Pyz\Yves\Application;

use Spryker\Yves\Application\ApplicationConfig as SprykerApplicationConfig;

class ApplicationConfig extends SprykerApplicationConfig
{
    protected const HEADER_CONTENT_SECURITY_POLICY_VALUE = 'frame-ancestors \'self\'; sandbox allow-downloads allow-forms allow-modals allow-pointer-lock allow-popups allow-popups-to-escape-sandbox allow-same-origin allow-scripts allow-top-navigation; base-uri \'self\';';
}

Valerii Trots

The issue is known and there is a PR open to be pushed through usual release process.

giovanni.piemontese

should be this the fix -> https://github.com/spryker/application/releases/tag/3.30.0

Alberto Reyer

Which isn't working for the local environment.
After I added

$config[KernelConstants::DOMAIN_WHITELIST][] = $config[ApplicationConstants::BASE_URL_YVES];

to the config_default-docker.dev.php the header seems to be correct at the first look:

form-action 'self' [www.computop-paygate.com](http://www.computop-paygate.com) <https://yves.de.helukabel.local> 

But still the redirect from the confirm to the place order step is blocked in chrome.

As it isn't working locally I didn't even tried to roll out this patch to staging or production.

giovanni.piemontese

Where did u configured [www.computop-paygate.com](http://www.computop-paygate.com) ? In Domain Whitelist?

Alberto Reyer

That's coming from the config_default.php

giovanni.piemontese

ok.. because

$config[KernelConstants::DOMAIN_WHITELIST][] = $config[ApplicationConstants::BASE_URL_YVES];

does not seems to have this configured...

giovanni.piemontese

and u don't need yves url there

Alberto Reyer

I do need the yves url, because this is the basic problem with the redirects.
As long as we only have 'self' chrome and edge do not allow a redirect as a result of a form at all.
So if we add the yves url to the whitelist it should allow a redirect within the yves domain as result of a form, which is necessary to reach the place-order step

giovanni.piemontese

u have to configure computop-paygate domain in domain whitelist.. so i have understood..

can u please send me a screenshot of form taken from inspector..?