squarecandy

Hi Ibrahim –

Thanks for getting back to me and taking the time to look into this.

I recommend creating a separate IAM user with limited permissions specifically for FluentSMTP

Yes, that’s exactly what we already did. See the original post above. Properly limiting the permissions with a single IAM user per site is what is causing the issue.

FluentSMTP requires permission to list all SES Identities on the account in order to establish a connection

We already have “Action”: “ses:*” set which includes listing identities. But we also have restricted the “Resource”: to the specific site identities we want to allow for this client site, so that will block the “list all” action. If I make one IAM user for each client but give them all permission to access all SES Identities, then that still gives every site permission to see our complete client site list and to send emails from any of their domains at any time. There’s no point in making one IAM user per site if they can all access every authorized domain. For us that means if one site is compromised, a spammer could send emails out to their choice of 50+ authorized client domain names.

I realize that probably many of your users are more casual and need easy setup and also they will just be starting a new AWS account for only one company. The existing setup will work fine for those users. But for agency users, it would be great to have some kind of “advanced” mode or override to be able to set things up in this way where we truly can restrict the IAM user to sending from only specific authorized domains.

Yup, that’s working for me!

Thanks for the quick reply and for the awesome plugin. It’s very odd that the official Cloudflare WP plugin is so limited and actually causes more problems than it solves. Thanks for filling a need in the community with this great plugin!

Ok! I found the solution:

Just need to add if( $this->remove_cache_buster() ) return $location; near the top of function wp_redirect_filter in cache_controler.class.php

This matches the logic in function inject_cache_buster_js_code but it’s just not included in the redirect filter.

I’ve done some additional testing and found a bit more about what’s going on:

If you check the “Remove Cache Buster Query Parameter” this successfully marks the option as true in the options table. This basic test looks good and works:

$test1 = new SW_CLOUDFLARE_PAGECACHE();
$test2 = new SWCFPC_Cache_Controller( 'demo', $test1 );
echo $test2->remove_cache_buster(); // returns 1;

What it does do is successfully removes the inline JS code that modifies the links on the page. This take care of some but not all of the instances where the cachebuster appears. So the following things are now good:

• existing links on the page don’t have cachebusters added
• visiting pages like example.com/shop/ directly don’t add a cachebuster

But a few circumstances cause it to reappear:

• Anything that triggers a redirect causes it to be added. This could be as simple as leaving off the trailing slash – so example.com/shop/ is fine but example.com/shop causes a redirect to the version with the trailing slash and adds ?swcfpc=1
• Anytime you submit a form instead of following a link, the cachebuster is also added. For example visiting example.com/cart/ directly it’s fine… but if you go to a product page and add a product to the cart – then ?swcfpc=1 is tacked on to the end when you get to the cart page after the form submission.

Following… we just setup a new site with this and have set things up successfully using Cache Rules. It’s a pretty sweet setup actually!!! But we set them up manually, the plugin didn’t do it via the API.

Brilliant – thanks everyone!

Ok, yes I can confirm that 6.2.8 RC1 works fine without any code changes needed to ACF:FA for me as well. So maybe not worth trying to shoehorn a special fix and just wait for 6.2.8 to come out instead.

That’s great to hear the got back to you so quickly. Thanks for looking into it. Is there any documentation on the new filters?

+1 – experiencing this despite DKIM & SPF authorized transactional email sending via AWS SES that works for all other system emails.

Thanks for considering it! No timelines expected on a free plugin, just wanted to log the suggestion.

For kits intended for use on only one site, the security issue can be mitigated by restricting to a certain domain. But we have some cases where we want to keep it open so we can let a bunch of domains make use without having to login to fontawesome.com and allow each one individually.

also curious about this.

Fantastic, thanks! Look forward to testing this on the next release. We probably won’t get to testing the snippet before then, but I’ll let you know if we do.

We’ve been testing on 6.3.2 and it’s working great!

Thanks for your response and for looking into this.

Sounds great, thanks again for looking into this.

Thanks for the work you’ve done so far on this. It’s an improvement for sure. Some feedback/additional fixes to what you have implemented:

• tabindex="0" is now assigned to every title no matter what. This seems wrong as only some of them do something. It should only be applied to the items with the .has_desc class – so that only items that operate as a toggle for a lightbox or expanding section can be focused.
• The workflow in term of the tab order of things on the page works well when you first arrive. It also successfully focuses on the X/close button when you open it. However – once you close it, focus should be placed back on the .title.has_desc item you clicked on. This would let keyboard only users browser around the calendar easily. Give it a try – try to explore multiple popups using just the keyboard and not touching your mouse at all. You’ll see quickly how frustrating it is to have focus moved back to the top of the page when you close the lightbox.