Viktor Bijlenga

Thanks for implementing the cookie modal and CSP on the login page! That’s great progress for the next release. I totally get your concerns about adding cookie modals in iframes on other sites – it would feel awkward and intrusive.

Thanks for a great plugin and your excellent contributions to the WordPress ecosystem!

Thanks for looking into this!

Sounds great, Johan! Let me know if there’s anything I can do to help.

I’ve noticed the same issue, which makes this very similar to my support thread: Ajax URL Issue with Consent Saving

I believe the problem is that the plugin assumes wp-ajax is located in its default location. However, in a subfolder installation, this is not the case. As a result, the AJAX request used to save data to the database fails.

Wouldn’t it be a good idea to add a Content Security Policy (CSP) to the login page as well? This would make it more difficult for unverified third-party domains to receive data from wp-login.php. I’m not an expert on this, but it seems like a logical security measure.

WordPress provides the login_enqueue_scripts hook, which allows scripts and styles to be added to the login page. However, since CSP is not currently applied to wp-login.php, any scripts added through this hook would not be restricted by a Content Security Policy. This means that if a malicious plugin or compromised code enqueues a script via login_enqueue_scripts, it could execute freely on the login page and potentially send user information to a third party.

WordPress generates URLs for “share embeds,” which I think are used by the Embed block in the block editor. However, these URLs can also be accessed from the front end. These pages doesn’t contain the CSP as well at the moment.
Example on your site: https://followmedarling.se/om-follow-me-darling/embed/

Yes! We are using the Raw HTML form variant. Our issue is not related to that, since the RAW HTML works just as intended.

The HubSpot Form block has stopped adding the custom CSS classes to the block itself. As a result, the output no longer includes the additional CSS classes, which disrupts our system for applying different form styles as needed.

These classes used to be added to the wrapper div of the block, which is not the case anymore. Can this be fixed?

Here is a breakdown of the code differences, in images if it makes things more clear.

Previously the block output allowed this to be created:

These blocks seems to be corrupt these days as well, when we try to edit a page. Form blocks without the additional css-class, works just fine.

If we create a new HubSpot Form block, the output doesn’t include the additional CSS-class for dark-mode.

Let me know if there is anything else I can provide, to be able to debug.

Thanks for fixing this! Looking forward to the new version!

Great to hear that this will be solved in a future release! Feel free to mark this as solved.

I got a reply from Nets support regarding this issue. It might be a temporary issue on their end that’s causing the 404.

I would think that this is not related to Woocommerce but is something that needs to be resolved in our systems since the image file is located on our domain. However, I will leave it to our developers to investigate and determine what needs to be done.

We get the same problem on a website. I’m guessing that the warning is related to the function register_block_method in dibs-easy-for-woocommerce.php line 309:
https://plugins.trac.www.ads-software.com/browser/dibs-easy-for-woocommerce/tags/2.8.1/dibs-easy-for-woocommerce.php#L309

I’m not sure what the issue is, but if I comment out the function, the notice doesn’t appear.

• This reply was modified 1 year ago by Viktor Bijlenga.

Thanks Mia! Sounds like a lovely addition to a already great plugin. Any ETA on when the new version will be released?

• This reply was modified 1 year, 8 months ago by Viktor Bijlenga.

Sounds great Mia! Let me know if I can assist with testing or anything to make it happen. Thanks in advance!

When using nginx with a fast-cgi cache this is done by changing the cache key, to use the cookie as a variable. Would something similar be possible if using an advanced config in the .htaccess file

Example
https://viktorbijlenga.se/nginx-cache-based-on-cookies/

Hi @jonkastonka,

I think I’ve found a working solution for using the NGINX fast-CGI cache. I was using a directive that resulted in the cache being skipped when the plugins cookie was set.

# Don’t use the cache for users which have accepted cookies
if ($http_cookie ~* "cookies_and_content_security_policy") {
    set $skip_cache 1;
}

I want the cache to serve different versions depending on the values of the cookies_and_content_security_policy cookie, since users need different get pages which sends different headers/meta-tags for the Content Security Policy.

To be able to do that, I needed to use the fastcgi_cache_key directive. If you use NGINX as a proxy (in front of Apache), I think the directive should use the proxy_cache_key instead, but I haven’t tested that.

In my case, the directive look like this:
fastcgi_cache_key "$scheme$request_method$host$request_uri$cookie_cookies_and_content_security_policy";

This is located in the nginx.conf for the current site. In my case, it was located at /etc/nginx/sites-available/SITENAME

Using this type of NGINX cache configuration, pages will be cached separately for different settings.

NOTE: If the site contains a large amount of pages, this might result in a lot of cached pages, since every page will be changed multiple times. This might be something to look into since it might require a lot more space.

If you spot an error, or this sounds wrong. Please feel free to improve the solution. Thanks in advance.

Follow up: This issue is solved with the release of version 1.94 and above of the plugin. Thanks for your work @jonkastonka!

Custom path for Bedrock:
Add cookies-and-content-security-policy-vars.php to the plugins folder and use the following settings for wp_load_path.

<?php
$wp_load_path = dirname( __FILE__ ) . '/../../wp/wp-load.php';

Sidenote: I propose that the solution of this issue is refactored in favor of using wp_localize_script() sometime in the future.
Related reading: https://ottopress.com/2010/passing-parameters-from-php-to-javascripts-in-plugins/