tezalsec

Hi @fbrevo , thanks for responding, but there was no need, I had already initiated the support request as suggested. I just wanted to close this topic explaining the cause of the issue.

I just noticed I forbid ico extension in a htaccess file in the wp-content folder, created years ago. ??
So consider it solved. Not taking away having foreign ico files fetched, with possible mimetype issues, is still something to take serious and maybe should be avoided.

Thanks.

• This reply was modified 3 months, 3 weeks ago by tezalsec.

Thanks for the response. I never realized MainWP was fetching those, and I have never seen them as I have apparently hidden them from the start, deeming them unnecessary bloat.

I do wonder if it is a good idea to just fetch them. I read about how it can be unsafe to host ico files, especially in other locations than root.

Another thing is that often people just rename their png to ico extension, which means by fetching them you invite mimetype errors to the MainWP dashboard site. This might be the case with my sites (as favicon.ico in root), but they never triggered any server errors or WordPress rejects.

Maybe you could just check the mimetype before rendering and fallback to an image of your own in case of a fetched ico file with wrong mimetype. WordPress itself rejects that too…

What is the “Edit page of a Child Site”? To what page are you referring?

I assume it would be a good idea to do something about this anyway. Either convert to png, or check mimetype before rendering, or not download them at all when disabled in the table view, or making downloading them optional in the settings. For security and WordPress conformity reasons. I shouldn’t have to do a feature request for that.

• This reply was modified 3 months, 3 weeks ago by tezalsec.
• This reply was modified 3 months, 3 weeks ago by tezalsec.

For the sake of completeness, I’ll share here that I found the cause of the issue.

Your use of an ico file in the admin menu triggered a “client denied by server configuration” rule in the fail2ban software on the server. Explaining the “DNS issue”…, since my IP just gets banned after a few pageloads in the backend.

Entry causing it:? [Tue Nov 19 14:40:20.005635 2024] [access_compat:error] [pid 1977:tid 140082321266240] [client xxx:0] AH01797: client denied by server configuration: /var/www/vhosts/xxx/httpdocs/wp-content/plugins/mailin/img/favicon.ico

Fortunately the image file only loads in the backend and not in the frontend, otherwise all visitors would be banned.

I have noticed this log entry for a long time, apparently my server, using DEFAULT apache rules, is not happy with your use of an ico file here. But it never caused any problems, until recently. All other wordpress plugins use png, svg, etc.. for their admin menu image files and they do not trigger same errors. Maybe it is an idea for you at Brevo to change the .ico extension into .png ? I am sure it will make many users happy, and may also speed up loading time in the backend and create less error logs.

So hereby a request to the developers: change the ico file into a png file in the admin menu to become more in line with other plugins and cause less errors.

Added: I noticed the file is already an actual png file, just posing as ico extension, causing a mimetype error. WordPress rejects this practice, explaining why it is not shown in the menu.

No response, guys? I hope you can help me out here.

I tested further by rolling back versions up to 3.1.83, but they all had the same issue. I do not know how to debug this further. The only thing really helping so far is turning off your plugin…

Just wanted to add that this should have been communicated more explicitly.
Just spent hours trying to figure out why my product image would not save.

Eventually, it was the WC log that hinted me towards your plugin’s errors.
What is the point of deactivating an extension plugin and not removing it alltogether when folks could easily reactivate it later, assuming it has still value.

Either communicate more clearly (persistent banner until the plugin is removed) or have the core plugin not just deactivate but delete the extension plugin, I would say…

I too came here to ask how to dismiss the notice permanently. Should there not be a solution to do this without adding a filter code?

Never mind, I forgot to set the right hostname in the new configuration of the 2.x plugin.
Thank you.

Hi @carolm29,

thanks for your quick reply. Some more research led me to just disable the order attribution tracking (https://woo.com/document/order-attribution-tracking/) , which I don’t use anyway. This solved the problem, and I am gonna leave it at that.

To answer your questions:
– no use of plugins interfering with coupons
– all themes and plugins were updated
– it is no cache or WAF issue
– it only happened in Brave fullscreen. Firefox fullscreen and Brave Mobile gave no issues.
– I did disable tracker blocking by the browser for the site, but the issue remained.

Hope this helps. Thanks again.

Good to hear, and I can confirm, I can reach you website now!

Hi, no problem, i’ll hack the names of the cookie name then, only two occurrences, I see.

My software is Malwarebytes, I am using it with default configuration. It could be a false positive, I dont know, but it does not allow me on your website. Something I almost never experience on websites. When I click the link the Malwarebytes warning is showing me, I end up on this page:

https://www.malwarebytes.com/glossary/compromised?lang=en&affiliate=119603&ver=4.6.1.280

Regards

Sorry to say, I applied your update 4.6.1 on another website, skipping 4.6.0, but I got the same error as above…

Isn’t everybody using opcache these days?

Glad to be of help, hope you figure it out.

By the way, I said “I would still give you 5 stars”, but just noticed I already did in the past.

Highly appreciate your attitude towards users. ??

Very clear, thank you, Jose! I will consider the PRO version in the future! ??

• This reply was modified 1 year, 9 months ago by tezalsec.

Thanks for explaining and for all the work you put into it. I did not know about the prepare_field filter, I’ll give it a try.
I haven’t had any compatibility?issues yet with this plugin and the new ACF version though.

All the best.