CDN CORS issue

[elliotks]

Hi,

After updating from 4.0.2 to 4.0.3? I started noticing an issue where font-awesome icons were not loading. I also noticed the site is trying to load /content from my configured CDN url I use for images. So instead of https://pixelsrv.com/content/... it's trying to use https://i.pixelsrv.com/content/...

Settings -> External Services

Settings -> External Storage (SFTP)


The .htaccess file was updated just to see if that would resolve but it did not.

# CORS header (avoids font rendering issues)(replace dev\.local with your domain\.com)
 SetEnvIf Origin ^(https?://.+\.pixelsrv\.com(?::\d{1,5})?)$   CORS_ALLOW_ORIGIN=$1
 Header append Access-Control-Allow-Origin  %{CORS_ALLOW_ORIGIN}e   env=CORS_ALLOW_ORIGIN
 Header merge  Vary "Origin"

Maybe with the upgrade to 4 I didn't do something right?

For the CDN configuration
▶ Reproduction steps

1. Upgrade from 4.0.2 to 4.0.3
2. Have CDN subdomain configured. (i.pixelsrv.com)

😢 Unexpected result




📃 Error log message

 

[Rodolfo]

🔒 This bug report is locked pending 60 day resolution. Having same issue? Give a like to say "me too".

 

[Rodolfo]

• The CDN at https://v4-admin.chevereto.com/settings/system.html#cdn is for your website, not for External Storage.
• The CDN at https://v4-admin.chevereto.com/features/external-storage.html#storage-url-with-cdn is for External Storage CDN.
• You can use the same CDN for website and external storage, but it means that the external storage is phony, in that case you should be using Local API External Storage.

Googling the error: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin

The response to the CORS request is missing the required Access-Control-Allow-Origin header, which is used to determine whether or not the resource can be accessed by content operating within the current origin.

 

[elliotks]

Hi Rodolfo,

I sent you a PM a while ago with the following, but you might have missed it.

The issue was resolved by Disabling CDN in the System settings. But just Disabling is not good enough. I had to remove the CDN URL as well before noticing the change. I have not touched that settings since V3. In the (chv)_settings table cdn = 0, so maybe the script is only checking the cdn_url field and excluding the check to see if the cdn = 1? This is what could gather, perhaps it's within the functions.php file?

$ egrep -rn "cdn" ./app/
./app/legacy/routes/dashboard.php:1351:                if (isset($POST['cdn']) && $POST['cdn'] == 1) {
./app/legacy/routes/dashboard.php:1352:                    $cdn_url = trim($POST['cdn_url'], '/') . '/';
./app/legacy/routes/dashboard.php:1353:                    if (!is_url($cdn_url)) {
./app/legacy/routes/dashboard.php:1354:                        $cdn_url = 'http://' . $cdn_url;
./app/legacy/routes/dashboard.php:1356:                    if (!is_url($cdn_url) && !is_valid_url($cdn_url)) {
./app/legacy/routes/dashboard.php:1357:                        $validations['cdn_url'] = [
./app/legacy/routes/dashboard.php:1362:                        $POST['cdn_url'] = $cdn_url;
./app/legacy/routes/dashboard.php:1363:                        $handler::updateVar('safe_post', ['cdn_url' => $cdn_url]);
./app/legacy/install/installer.php:218:        'cdn' => 0,
./app/legacy/install/installer.php:219:        'cdn_url' => '',
./app/src/Legacy/functions.php:1062:    define('URL_APP_PUBLIC_STATIC', Settings::get('cdn_url') ?? URL_APP_PUBLIC);
./app/src/Legacy/Classes/Settings.php:306:                    'cdn' => false,
./app/src/Legacy/Classes/Settings.php:307:                    'cdn_url' => ''

Anyway, the site is functioning properly now.

Thanks,

 

[Rodolfo]

Thanks for reporting this, I can confirm a bug in the CDN website settings. Patch will be available in release v4.0.7.

 

[Rodolfo]

🎉 Fixed in 4.0.7