tapulator's Replies | ww.wp.xz.cn

Forum Replies Created

Viewing 9 replies - 1 through 9 (of 9 total)

Forum: Plugins
In reply to: [Contact Form 7] Is this a valid antispam strategy?

Thread Starter tapulator
(@tapulator)

2 days ago

Yeah, I’m not a big fan of this whole avoid US tech agenda either. Seems very unlikely to me that US companies will ignore the data privacy needs of their EU customers. But that’s not for me to decide.

Actually, the first thing I did was reading your blog post about the antispam integrations CF7 offers. After that I recommended Turnstile and Recaptcha as second option. Well, you know the result. (:

But why do you consider Honeypots not as spam protection at all? Are they mostly ineffective because spambots are JS-enabled or smart enough to circumvent them these days?

Forum: Plugins
In reply to: [Contact Form 7] Is this a valid antispam strategy?

Thread Starter tapulator
(@tapulator)

2 days, 18 hours ago

Thanks for your reply (and providing this great plugin), @takayukister! 🙂

To be clear: I don’t assess data privacy compliance nor evaluate it. That’s not my responsability in our organization.

Our data privacy officer doesn’t want any US-parties involved, since it’s currently highly unclear if the US will honor its data privacy agreements with the EU in the near future.

Honeypots seem perfect considering data privacy because they simply don’t use/rely on user data. Though they are far from being a perfect antispam tool because of the aforementioned characteristic.

I don’t know how severe the (theoratical) hit on efficiacy would be in our case.

Just fishing for some feedback/recommendations here. I’m a seasoned developer but spam has never been a real problem for me, so I don’t have much experience involving antispam under my belt.

Forum: Plugins
In reply to: [Contact Form 7] Is this a valid antispam strategy?

Thread Starter tapulator
(@tapulator)

3 days, 6 hours ago

If the endpoint accepts requests from anywhere, frontend-only protection would be useless.

Well, looks like you can post form data from anywhere using CF7’s REST API. As long as you know _wpcf7_unit_tag , which shouldn’t be too hard to obtain, you can fire away.

That could explain receiving spam literally every second from time to time.

Hm, I’m afraid restricting the form to JS-users only won’t reduce spam significantly. Or is it rather unlikely that a spammer takes the effort to crawl the unit tag?

Forum: Plugins
In reply to: [Fix Alt Text] Scan support for basic auth pt. 2
Thread Starter tapulator
(@tapulator)

7 months, 1 week ago
Sure!

Here’s the authorization part of my server config:
```
AuthType Basic
AuthName "Some text"
AuthUserFile /path/to/.htpasswd
<RequireAny>
  <RequireAll>
    Require expr %{REQUEST_URI} =~ m#^/wp-admin/admin-ajax.php$#
    Require expr %{QUERY_STRING} =~ m#^action=fixalttext_scan&nonce=[a-z0-9]{10}$#
  </RequireAll>

  <RequireAll>
    Require expr %{REQUEST_URI} =~ m#^/wp-cron.php$#
    Require expr %{QUERY_STRING} =~ m#^doing_wp_cron=[0-9]+.[0-9]{22}$#
  </RequireAll>
  
  Require user some_user
</RequireAny>
```
Needs to be tuned to one’s setup, obviously. (:
Forum: Plugins
In reply to: [Fix Alt Text] Scan support for basic auth pt. 2

Thread Starter tapulator
(@tapulator)

7 months, 1 week ago

I consider my problem solved.

One just has to make sure that Fix Alt Text’s requests against /wp-admin/admin-ajax.php and /wp-cron.phpare processed correctly by one’s server.

My solution was to punch 2 holes in the basic auth for the requests mentioned above. RequireAny and Require expr are your friend if you use Apache. No additional plugin needed.

There may be better, safer ways but I’m okay with the current solution.

Forum: Plugins
In reply to: [Fix Alt Text] Scan support for basic auth pt. 2

Thread Starter tapulator
(@tapulator)

7 months, 1 week ago

I tested the “selective” basic auth outside WordPress. It works there, but not when applied on the WordPress directory.

And another failed assertion! 😄

My regex was wrong, so the request would still require basic auth.

With the fixed regex the scan is running. Will take some time though, because the website contains many images.

Looks good so far. 👌

My comment about “make sure the hosting is compatible” was the reason I asked who your hosting was. So that I (not you) could make sure it was compatible as some have read-only directories which cause issues at the moment.

Ah, okay! I have full control over the file permissions. That won’t be a problem.

Overall I’m not sure if your plugin should address the issues WordPress has with basic auth, as you already mentioned in the other thread.

I get the feeling that WordPress wants its users to rely on the build-in password protection. (It’s another topic, but can I hide a WordPress instance this way completely?)

PS: Have a nice flight! 🙂

Forum: Plugins
In reply to: [Fix Alt Text] Scan support for basic auth pt. 2

Thread Starter tapulator
(@tapulator)

7 months, 1 week ago

I compared the debug and access logs of a working instance (without basic auth) and the broken instance (with basic auth).

My conclusions:

I have to correct my assertion.

Neither the notifications nor the PHP log report any error. But these 2 consecutive messages in the plugin’s debug log caught my attention:

[…] – ajax – info – Fix Alt Text: Dispatching background scan process
[…] – ajax – info – Fix Alt Text: Not doing cron.

That doesn’t seem right. To my understanding, after dispatching the scan, there should be a cron job running.

These messages also occur in the working instance’s debug log, so there’s no problem.

My 2nd finding on the other hand seems to pinpoint the culprit, the unauthorized request:

Furthermore in the access log I see unauthorized requests to /wp-admin/admin-ajax.php?action=fixalttext_scan&nonce=some_nonce although the user is considerd logged in when the action hooks like wp_ajax_fixalttext_scan_start are fired.

This request triggers the crucial maybe_handle callback.

I don’t know if the login state really matters though.

The strange thing is: Disabling basic auth for the critical request doesn’t help. The server still responds with a 401 code. (I tested the “selective” basic auth outside WordPress. It works there, but not when applied on the WordPress directory. Doesn’t make much sense to me right now.)

Forum: Plugins
In reply to: [Fix Alt Text] Scan support for basic auth pt. 2
Thread Starter tapulator
(@tapulator)

7 months, 1 week ago
Hey @stevenayers63,

thanks for your help!

Here’s your desired information:
- WordPress version: 6.8.2
- PHP version: 7.4.33
- Web server: Apache 2.4.65
- Hosting: Strato WordPress Hosting (It’s shared hosting. I would say Strato is Germany’s biggest hosting provider.)
Make sure we are compatible

How do I do that?

Are other cron jobs running? Install Cron Control to see if all your wp cron jobs are stacking up and past due.

I see several cron jobs, none past due. fixalttext_scan_cron runs every minute.
Forum: Plugins
In reply to: [Embed Privacy] CSS doesn’t load in combination with some Elementor widgets

Thread Starter tapulator
(@tapulator)

1 year, 8 months ago

I dug into the source.

Apparently the stylesheet is only inserted when the “old/original” and “new/replaced” content are not identical, what is for some reason the case when the described widget combination is used.

I can’t wrap my head around the logic behind the multiple content manipulation passes and the content comparisons, but I’m sure they’re used for a good reason. Unfortunately, this means I can’t point my finger on the code causing the described behavior.

My workaround:

I hooked up the filter “embed_privacy_overlay_replaced_content” and print the stylesheet (and other assets) in the callback. My thinking: If content is replaced, the stylesheet is definitely needed. Multiple printing shouldn’t occur, since the method “printing_assets” also checks if the assets were already printed.

Seems to work.

Do you have suggestions to the presented workaround or know a better one? Maybe even know how to fix this bug properly?

Viewing 9 replies - 1 through 9 (of 9 total)