vegasmerch

I just wanted to post that I, too, had the same problem. Another user posted to disable the caching of the checkout page in the Autoptimize plugin… Unchecked the box and cleared the cache – problem immediately fixed.

It seems like some other might be having different problems… the symptoms for me were that the option showed up on checkout, fields for square were present, but clicking on them did nothing and the customer could not enter their information.

Admittedly, I didn’t actually read them, but it may be in the author’s best interest, if not already there, to add a bullet point to the release notes noting the compatibility issue with this option in Autoptimize.

I’ve been having the same problem. Rules have not updated since 7/22/19. I’ve taken a pcap of the update transaction and the VPS appears to successfully reach noc4.wordfence.com although the session is SSL encrypted, so I do not have any visibility into the actual transaction.

edit to add: My rules file shows the last update on 7/22 at 02:22 UTC, symptoms are the same as poster above. Manual update indicates that I have used up all of my update attempts.

• This reply was modified 5 years, 6 months ago by vegasmerch.

Solved my own problem…

It appears user-settings.php was wiped out in the update and the script could not create a new one due to a permissions problem.

It looks like this was actually noted in the output after save, but because the text was listed within a green bar dialog I thought it was a successful save. It wasn’t.

To fix it, I touched user-settings.php in the plugin dir and then chown’d to the webserver’s user account.

I agree with @convexity and might suggest that a potential solution would be to require cache users to register, generate a hash that the new registrant must place into a text file on their website in a predetermined location, and have your bots verify the hash is present there at least one time before allowing further caching of the site’s content.

This way, you have some mechanism to verify that the requester actually has control of the domain in question before caching its content. This should also help you cut down on abuse of your API and should be fairly simple to implement.

>I checked your site and see no Photon URLs in your source, so this no longer >appears to be a problem for you.

There never were. That’s why I opened the ticket.

I have already checked my outbound traffic on posting new images and I don’t see any traffic being generated from my site to the Photon API. I highly suspect (and have found proof that) a 3rd party is using your API to rip off my images.

While it is a bit troubling that your service is able to be used as MITM with no authentication necessary for submitting images to the cache, it doesn’t really pose an issue for my use case other than not wanting association with the 3rd party sites that are abusing your services to download my images.

James,

There are no photon urls in my content and never have been.

That is why I have raised a ticket.

I will take a look at the api documentation but I am trying to figure out how my content got cached on your cdn in the first place.

Will the system simply cache content based on a request from anywhere with no security in place?

I believe a nefarious 3rd party is using your cdn service as mitm to steal image content.

As far as I can tell, my server has never sent a request to photon API to cache any images.

My image URLs do not point at Photon. All of the images are hosted directly on my own site. I don’t understand how/why my images are being uploaded to the Photon service?

I checked through my plugins but none of them mention making use of Photon for CDN or resizing.

What traffic would I need to look for that is uploading to the photon api? Would it be an outbound connection to i1.wp.com?

I would like to reopen this case. I am having the same issue the OP posted. I do not use the Jetpack plugin, do not have it installed on my site, and have never used it. I’ve never used the CDN functionality and my image urls point at my own website.

I have been having a problem with a negative SEO network hotlinking my images. I implemented config changes to thwart this and today, I am finding that some of the illicit sites have now moved to using what appears to be a mirror of my image directories on i1.wp.com. After doing some research into the issue, I landed here.

What I would like to know is how is it possible that my images are being mirrored on the wordpress CDN when I do not use or have installed the Jetpack plugin? Is there something else running in a default wordpress install that would cause this behavior?

I made some requests directly on the URI for images that I uploaded to my site today, and sure enough, they are present on i1.wp.com:

https://i1.wp.com/shopvegasmerch.com/wp-content/uploads/2019/04/DSCF1378.jpg

Also, I tried requesting an image that does not exist and immediately saw a connection from an IP that traces back to the wp image hosting. Is this intended functionality? How did my site end up on i1.wp.com in the first place? What mechanism is being used to notify i1.wp.com of updates to my content?

I have blocked my feeds and also implemented a rewrite rule to stop the scraping but I am trying to understand how my content ended up there to begin with? Is there a way to have the content removed? I do not want my business associated with the illicit sites that are using my image content!