ScrapeLock – Content & AI Bot Protection -- WordPress 插件

开发者	codebunnyhube
更新时间	2026年11月3日 03:31
PHP版本:	7.4 及以上
WordPress版本:	7.2
版权:	GPLv2 or later
版权网址:	版权信息

Most content protection plugins disable right click in the browser. Scrapers and AI crawlers never use a browser, so they are not affected. ScrapeLock works on the server, where automated copying actually happens, and keeps real visitors, customers and search engines unaffected. What makes ScrapeLock different

Real search engines vs. fakes. Googlebot, Bingbot, Applebot and Yandex are verified against their official IP lists and with reverse + forward DNS. Real crawlers are never limited or blocked; scrapers that only pretend to be Googlebot get a 403.
AI training vs. AI search. Training crawlers (GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider and more) are blocked, while AI search assistants (OAI-SearchBot, ChatGPT-User, PerplexityBot and more) can be allowed with one option and are verified with their official IP lists, so your site still appears in AI answers with a link.
Per-IP limits and temporary blocks. Separate limits for pages, searches and REST / GraphQL requests (IPv6: per /64 network). IPs that keep exceeding them are blocked for a while, optionally also at your CDN, and an invisible trap link catches bots that ignore robots.txt.
Private feeds with a token. XML feeds for price comparison sites, Google Merchant or an ERP are closed to everyone else. The token goes in a header or the URL, only its hash is stored, and it can be rotated with a grace period.
Your text stays out of the API. Post, page and product text is hidden from the REST API, WPGraphQL and full-text RSS for visitors, which are the routes scrapers use instead of the HTML.
Emergency Mode. One click during a scraping attack: stricter limits for 1 hour to 3 days, then your normal settings return on their own. When traffic suddenly jumps, ScrapeLock emails you with a one-click button to start it.
Monitor only. Try every setting without blocking anyone: requests that would be refused are logged as "Would block". New installs start this way for their first 7 days.
Lockdown. Freeze the whole site with a code from your authenticator app, so not even a stolen administrator password can change it.

Nothing can stop a determined human: whatever a visitor sees has already reached their device. ScrapeLock closes the automated routes and leaves traces: a block log, watermarks, a source link on copied text and a machine-readable rights reservation (TDM). Bots and limits

Generic HTTP libraries (curl, python-requests, okhttp and the like, used by apps and integrations) are not blocked by default; a strict option blocks them too, and the Log has an "Always allow this User-Agent" button.
Optional blocking of headless browsers and of scripts that copy a browser's User-Agent but not its headers. A carefully disguised automated browser is not detected this way; the limits, the human check and the bot trap still apply to it.
Extra limits for "page not found" (404) requests, sitemaps, visitors from data centers and, with WooCommerce, cart / checkout actions and coupon attempts. Verified search engines and real shoppers are not affected.
Optional human check: visitors who have not interacted with the page (scroll, tap, key) get a stricter page limit. No captcha; it works with page caches.
Optional country rules, from Cloudflare's or Bunny CDN's country header or the free DB-IP Lite database.
Optional pre-cache check (the limits and blocks also apply to pages served by a page cache such as WP Rocket) and early check (stops known bots and blocked IPs before the theme and the other plugins load).
Optional blocking at Cloudflare or Bunny CDN, with a "Test connection" that checks the token, the zone and the permissions in one click.
Always-blocked IPs / CIDR and referrer domains, usernames hidden from visitors, and Content Signals in robots.txt.
Trusted Proxy support for Cloudflare, Bunny CDN and reverse proxies, so the real IP cannot be spoofed. Works with the Cloudflare plugin (APO).
Presets (Balanced, Strict, Maximum), undo for presets and imports, export and import of the settings, and a block log with a 24-hour summary and automatic deletion.

Feeds, API and server rules

RSS with a short excerpt only, or disabled. With full text, an optional "The post … first appeared on …" line links republished copies back to the original.
Private XML feeds (Skroutz, BestPrice, Google Merchant, ERP) with token rotation and per-feed statistics.
Optional: hide the REST API map from visitors, turn off pingbacks over XML-RPC, and see which REST routes anyone can call without logging in.
Hide the versions of WordPress, PHP and the plugins.
Ready-made Nginx, Apache and Cloudflare rules for your own site, so cached pages and static files are protected too.

Site Health, WP-CLI and AI agents

Tools → Site Health warns about settings that do not work as intended and has a ScrapeLock section in the Info tab.
WP-CLI: wp scrapelock status, block, unblock, blocked, emergency, log, check --ip=<ip> (what ScrapeLock would answer, without side effects), settings and lockdown status.
Abilities API (WordPress 6.9+) for administrators: read the summary, block or unblock an IP and start Emergency Mode from an AI agent or MCP client. None of them unlocks Lockdown.

On the page and images

Block text selection, right click, copy, drag and common shortcuts, or allow copying with the source link appended. Text selection stays allowed by default, because blocking it also stops screen readers' "read selection" and translation tools.
Printing with the page link at the bottom, or no printing; optional page blur on screenshot shortcuts; no framing by other sites.
AI opt-out declaration (TDM): header, meta, /.well-known/tdmrep.json, noai.
Watermark in a corner, the centre or repeated diagonally, optionally on the full-size image too. When the full size is not watermarked, visitors get the largest watermarked size instead, also in the WooCommerce zoom, lightbox and Store API. The clean original is kept, so the watermark can always be removed. Product images are not watermarked by default, because Google Merchant Center rejects them.

Lockdown

Freeze the site with one click and a code from your authenticator app (Google Authenticator, Microsoft Authenticator, Authy and the like). While it is locked, nobody can change plugins, themes, WordPress core, users, roles or settings from wp-admin, the REST API or XML-RPC, not even an administrator or someone who stole a password.
Administrators are frozen completely. Shop managers and other staff roles you do not tick keep their work (orders, products, coupons, posts, media), but not the rights that could take over the site.
Also enforced against code: if another plugin is exploited, it cannot activate plugins, change the site address or the admin email, add an administrator or unlock the lock.
Visitors and customers are not affected: they browse, order, pay, register as customers and comment as usual.
File integrity: a fingerprint of every PHP, .htaccess and .user.ini file is checked every hour while locked, and WordPress and the plugins from WordPress.org are compared with their official checksums. New or changed files are emailed to you and shown in Site Health; optional quarantine.
Sealed: the lock is signed with the keys in wp-config.php and kept outside the database (a guard file, a lock file, or a line in wp-config.php), so SQL injection in another plugin cannot unlock the site. Settings changed in the database are put back.
Unlock for 15 minutes to 2 hours for yourself only, or until you lock it again. Every lock and unlock is logged and emailed.
Lost your phone: ten one-time recovery codes, or define( 'SCRAPELOCK_UNLOCK', true ); in wp-config.php as a last resort.
The QR code is drawn in your browser and the secret is stored encrypted: it is never sent anywhere.

3.4.2

Fix: on sites served by several web servers that share one MySQL / MariaDB database, the Lockdown code check now uses a lock of the database server (GET_LOCK). All web servers wait on the same lock, values written in the database can no longer keep the owner's correct code "busy", and the lock is freed at once if a request dies while holding it. The lock file and the signed lock row are kept as the fallback (SQLite, database drop-ins with several connections, or when GET_LOCK is not available).
Dev: new filter pncp_lockdown_db_lock (bool) to turn the database lock off.
New: Lockdown on servers where WordPress cannot write to any folder of wp-content (no guard file and no lock file possible): after locking, the Lockdown page shows a line to add to wp-config.php by hand, define( 'SCRAPELOCK_LOCKED', '...' );, with a Copy button. The value is signed with the site's keys and names the lock and the address alerts go to. While it is there, if someone deletes, changes or puts back an older copy of the Lockdown data in the database, the site stays locked, protected settings are put back from their saved copy while it is there, and the alert goes to the address signed when the site was locked. A line from another site, or changed by hand, is ignored.
New: until the line for the current lock is in wp-config.php, the Lockdown page, an admin notice, Site Health (critical) and wp scrapelock lockdown status say that the lock is not protected yet. A line from an earlier lock is named, with the new line to replace it.
New: the same line can also be added when the guard file or the lock file is written, as one more copy of the lock outside the database (optional, shown on the Lockdown page).
Unlocking for a while works with the line in place, with no change to it. After an unlock "until I lock it again", the page, the email and Site Health ask you to remove the line. SCRAPELOCK_UNLOCK still opens the site with the line present, and a new app can be connected; afterwards the old line no longer holds the site locked.
Multisite: one line for the whole network (one wp-config.php, one lock of the network).
Known limit: the line cannot follow an unlock for a while that is ended early with "Lock again now". Putting back the database copy of that unlock re-opens it only for the browser session that unlocked. If the line is left in place after an unlock for good, a wipe of the Lockdown data locks the site again until the line is removed.
Fix: WooCommerce shop managers were always frozen by Lockdown (WooCommerce gives the role "edit_theme_options"), so a locked shop could not process orders. While the site is locked, shop managers now keep their work: orders and refunds, products and stock, coupons, reports and analytics, customers, posts, pages, media and comments. Only what can take over the site stays frozen for them: plugins, themes, the Customizer, menus and widgets, the file editor, creating or promoting users and editing staff accounts, WordPress and WooCommerce settings (payment methods too), import and export, and HTML that can carry scripts. Their own email, password and application passwords stay frozen too.
Change: the same applies to every role that is not ticked under "Who is frozen while locked" and has any of those rights (for example an unticked Editor keeps editing but loses unfiltered HTML while locked). Administrators, and every role that can manage plugins, themes, users or settings, are always frozen as before. Shop managers are no longer ticked by default; tick the role to freeze it completely.
New: the Lockdown tab explains what a locked site still allows each role (administrators, ticked roles, unticked staff roles, other roles), the report lists the accounts that keep their shop and content work, and staff who keep their work see a notice that says what they can still do. Site Health and wp scrapelock lockdown status list the roles that keep their work while locked.
Dev: new filter pncp_lockdown_limited_caps (string[]) to add capabilities refused while locked to roles that keep their work; the built-in ones cannot be removed. New PNCP_Lockdown::limited_roles() and PNCP_Lockdown::staff_level().
New: WooCommerce cart and checkout limits per IP (Limits tab, shown only when WooCommerce is active). Adding, changing and removing cart items, removing coupons and placing or paying for an order count toward "cart and checkout actions per minute" (default 60, 30 in Emergency Mode). Coupon codes tried count toward "coupon attempts per minute" too (default 10, 5 in Emergency Mode). Covered: the Store API (block cart and checkout, also each request inside a Store API batch), the wc-ajax cart actions, the same actions through admin-ajax.php (woocommerce_apply_coupon, woocommerce_add_to_cart and so on) and the classic forms (?add-to-cart=, the cart page coupon form, the checkout form). Address, shipping rate and cart fragment updates never count, so a real shopper is never affected. Above the limit: 429 with Retry-After, a Store API JSON error or a wc-ajax / admin-ajax JSON error. Staff who can edit posts or manage the shop, exempt users and always-allowed IPs are never limited. In "Monitor only" it only logs what it would block. 0 turns each limit off. The settings are in export / import and wp scrapelock settings.
New: the log names the new reasons "WooCommerce cart / checkout actions per minute" and "WooCommerce coupon attempts per minute"; Site Health shows the two limits when WooCommerce is active.
Fix: a request that ScrapeLock refuses inside a REST batch (for example a blocked IP calling the WooCommerce Store API batch) no longer ends the whole batch with a fatal error (HTTP 500) on WordPress 7; it gets its own 403 / 429 inside the batch answer.
Fix: with watermarking on and "Watermark the full-size image too" off, visitors could still get the clean full-size image: the WooCommerce product gallery zoom and lightbox (data-large_image, the link around each gallery image, PhotoSwipe), the image a variation switches to, the product's structured data, the Product Gallery block and the Store API (images[].src) all pointed at the unwatermarked original. Visitors now get the largest watermarked size instead (one with the image's proportions where there is one), with its real width and height, so zoom and the lightbox keep working. Wherever WordPress would hand a visitor the clean full size of an image that has watermarked sizes (size "full", or a size the image does not have), the largest watermarked size is used. Staff (users who can edit posts, so shop managers too), exempt users and the admin screens keep the real full size, also in the WooCommerce REST API (wc/v3). The srcset behaviour is unchanged. New filter pncp_watermark_replace_full (return false for an attachment to keep the old behaviour).
New: "Test connection" under "Blocking at the CDN" checks every step in one click and says what to change: Cloudflare can be reached (and how fast), the API token is valid and active (or disabled, expired, not valid yet, or expiring within 14 days), the zone exists and is active (or still pending, paused or moved) and which plan it has, the token may read and edit the IP Access rules (a test block at 203.0.113.x is added, found and removed again), how many IP Access rules the zone has, and how much of Cloudflare's API rate limit is left. Account-owned API tokens are recognised too. The same check runs when the connection is saved, and its result is shown on the settings page also when saving was refused.
New: "Copy diagnostics" gives the result of the check as text for a support request: each step, the zone, the plan, the versions and Cloudflare's Ray IDs. It never holds the token.
Fix: a wrong zone ID no longer makes ScrapeLock give up on the addresses it was blocking. Cloudflare's "invalid zone" and "could not route" answers (HTTP 400 or 404) used to be taken as "this one address was refused", so those bans were never sent again once the zone ID was corrected. They now stop the run like a refused token, with a clear message.
Fix: an HTML page instead of an API answer (a Cloudflare error page such as 520 or 522, a Cloudflare "access denied" page for the server's address, a page of a proxy in between, an empty answer) is no longer taken as a refused token (which paused blocking at the CDN for an hour) or as a refused address (which gave up on that ban). It is retried within minutes, and the message says what happened.
Cloudflare: clearer messages for each kind of refusal by Cloudflare: token not in the format of an API token (or a Global API Key), unknown or deleted token, token without the permission or without this zone, unknown zone ID. Messages include Cloudflare's error codes and Ray ID.
Cloudflare: when Cloudflare cannot be reached, the message says why where it can: no answer within 10 seconds, DNS failure, outgoing connections blocked by the host's firewall, an SSL/certificate problem, or WP_HTTP_BLOCK_EXTERNAL in wp-config.php (with the WP_ACCESSIBLE_HOSTS fix).
Cloudflare: looking up ScrapeLock's own rules at Cloudflare also works when Cloudflare's answer has no paging information, and when Cloudflare refuses the IPv6 search filter (the search then runs without it).
Change: a run of the CDN sync starts no new API call after 15 seconds (was 20), and earlier when the request has less time left (for example after other scheduled tasks ran first in the same cron request), so it always ends within PHP's time limit; what is left is done by the next run a minute later. The plugin no longer raises the time limit itself.
Dev: new filter pncp_edge_rule_limit (default 50,000, Cloudflare's documented limit per account on every plan), the number of IP Access rules used by the "Room for blocks" check.
Plugin Check: ScrapeLock no longer calls set_time_limit(). The Lockdown file check reads files for at most 25 seconds per request (less when PHP's time limit leaves less), and on a very large site it goes on in the next scheduled run, started right away, instead of stopping with an incomplete pass. A fingerprint or a check is stored only once every folder was read, so nothing is compared half-way. Where the pass stopped is kept signed and tied to the current fingerprint: a value written in the database cannot hand it a list of "already read" files, and a record that does not match is never used to take a new fingerprint. An unlock, or the end of the lock, drops a pass that is still going on.
Plugin Check: the comparison with the official WordPress.org checksums works the same way: the plugins it has no time for are compared in a run scheduled right away (before, they were listed as "cannot be compared" until the next day), and the Lockdown tab says when a fingerprint, a check or the comparison is still running in the background.
Plugin Check: removing the ScrapeLock block from the uploads .htaccess checks the file with wp_is_writable().
Fix: Lockdown on several web servers sharing one database: if a connection to the database holds the code-check lock for longer than any code check takes (someone with the database password can see its name in the list of running queries), codes are checked with ScrapeLock's own lock after at most one 5-second wait, so app and recovery codes still work. It is logged and emailed (at most once an hour). If codes still answer "busy", the message now names SCRAPELOCK_UNLOCK.
Fix: several web servers with their own wp-content: an unlock (or a new lock) done on one server no longer makes the others report "Lockdown data was changed outside WordPress". A newer lock, correctly signed, is followed and the server's own guard file is brought up to date; older or unsigned data is still refused. An unlock for a while is followed only by servers that are unlocked for a while themselves: the others stay locked until you unlock on them too (or lock again), because a copy of that unlock put back in the database after you locked again would look the same to a server that missed the lock. "Lock again now" works from any of them and locks them all.
Fix: while locked, shop managers can edit customers through the WooCommerce REST API (wc/v3/customers) too, as in wp-admin and wp/v2/users. Staff accounts stay frozen.
Fix: on the classic cart page, each "Apply coupon" counted as two coupon attempts (the cart reload after it was counted too), so a shopper could be refused after 3 codes in Emergency Mode. Only the attempt itself counts now.
Fix: with "Watermark the full-size image too" off, visitors no longer get the clean full-size image from the REST API media endpoint (source_url, guid, description) or the attachment page (its link, and its redirect to the file when attachment pages are off).
Fix: Cloudflare "Test connection": a test block that could not be removed is now queued and removed by the next run (or listed for removal by hand if Cloudflare keeps refusing), instead of staying at Cloudflare.
Fix: Lockdown on several web servers: requests that keep sending wrong codes to one server, with the lock values copied and written back in the database, could keep a correct code on another server answering "busy" for as long as they kept going. A code that is correct (the app's current code or an unused recovery code) now goes before the others and gets in within about two seconds; wrong codes wait. This also covers sites without the database lock and without a writable lock file.
Fix: the record of a database connection found holding the code-check lock is now signed. A value written in the database can no longer make a real code check look like an outside holder (which let more wrong codes be checked than the hourly limit) or reset when the administrator was last emailed about it. While such a holder was seen in the last day, requests that hold the database lock also take ScrapeLock's own lock, so the two never check codes at the same time.
Readme: a shorter description, the Cloudflare checks of "Test connection" listed under External services, and the changelog of 3.4.0 and earlier moved to changelog.txt, so the readme stays within WordPress.org's limits.

3.4.1

Fix: turning "No PHP in the uploads folder" off, or deleting the plugin, left one more blank line in wp-content/uploads/.htaccess each time (since 3.3.2). The line break WordPress adds before the ScrapeLock block is now removed with the block, so the file is left exactly as it was before ScrapeLock wrote to it. Blank lines already left there by earlier versions are not touched.
Lockdown: someone with a stolen administrator session and direct write access to the database could keep the owner's correct code (or recovery code) answering "busy" for up to about 20 seconds, by copying the code-check lock while it was held and writing it back after it was released. Code checks on the same server now also wait for each other on a small lock file (scrapelock-lockdown.lock, in wp-content/mu-plugins, or in wp-content when that folder cannot be written), which the database cannot change: a lock value written back in the database no longer delays anyone, while wrong codes are still checked one at a time and counted exactly. A code check whose request ended without releasing the lock no longer blocks the next one for 5 seconds either. The lock file only holds a random name; it is removed when the plugin is deleted.
Security: Lockdown's copy of the wrong-code counters is no longer a .json file in wp-content/mu-plugins that anyone could download. It is now a PHP file that stops at its first line (a web request to it shows nothing), in its own folder wp-content/mu-plugins/scrapelock-lockdown-data/ (with an index.php), which WordPress never loads as a must-use plugin.
The scrapelock-lockdown-fails.json file left by 3.4.0 is read once more and then deleted, so its counters and lockouts still count after the update. This now happens during the update itself (and again in the hourly check if the file could not be moved yet), not only once a code is checked or a ScrapeLock settings page is opened.
The file integrity check does not report the counters file or its folder while they hold exactly what ScrapeLock writes. If code is added to them, or another PHP file appears in that folder, it is reported like any other file.
The counters folder is removed with the Lockdown guard: on unlock, on deactivation and on uninstall.
Lockdown: when the guard file cannot be written and you lock with "Lock without the guard file (weaker)", ScrapeLock now writes a signed lock file outside the database instead, in the first of wp-content/uploads/scrapelock-lockdown/ and wp-content/scrapelock-lockdown/ that PHP can write to directly. It holds the lock, its generation, the lock time, the address alerts go to and, when it is not too large, the signed copy of the protected settings (as the guard does). Someone who can only change the database can no longer make a site locked this way look as if it had never been locked: with the lock data deleted, stripped or set back (also with the stored version set back to an older one), the site stays locked, the protected settings are put back from the copy and the alert goes to the address signed when you locked.
The lock file cannot be shown by the web server: it starts with a line that stops PHP, it is read as data and never run, its name is made from the security keys so it cannot be guessed, and its folder has an index.php and an .htaccess that denies access. It is only read when there is no guard file (at most two quick file checks per request while there is none).
The lock file is removed when you unlock "until I lock it again", remove the app, connect a new app, deactivate or delete ScrapeLock, and when the guard file can be written again. The file integrity check does not report it, or its index.php and .htaccess, while they hold exactly what ScrapeLock writes; code added to them is reported.
The weaker lock still needs the checkbox. Its warning now says what it keeps: with a writable folder for the lock file, the lock survives a wiped database, but the active plugins and the theme are not kept from the start of every request and someone who can change the database could still deactivate ScrapeLock itself. When no folder can be written at all, it says plainly that everything is then in the database only and that a full wipe cannot be noticed. Site Health and the log say which of the two it is.
Recovery with SCRAPELOCK_UNLOCK in wp-config.php after the Lockdown data was deleted from the database: connecting a new app, or removing the app, now also removes the guard file or the lock file that still said "locked". Before, the new app was not saved in that case, and after removing the app the site locked itself again on the next request.
Fix: a guard file or lock file from a backup taken while the site was locked, put back after you unlocked "until I lock it again" (for example by restoring wp-content/uploads or wp-content/mu-plugins), no longer locks the site again with no way out. Before, the owner was frozen, the page said "unlocked" while the site stayed locked, recovery codes were used up and locking again answered with an error, so only SCRAPELOCK_UNLOCK or deleting the file by hand helped. An unlock now signs which lock it ended: an older file found afterwards no longer counts, is removed and is noted in the lockdown log. A file that still says "locked" while the database does not (for example one put back after unlocking with an earlier version) is now removed when you unlock with the app or a recovery code.
Security: with the weaker lock (no guard file), the wrong-code counters were kept in the database only, so someone with a stolen administrator session and direct write access to the database could delete them before each try and guess app codes without limit and without any alert. A signed copy of the counters is now kept next to the signed lock file (same folder, a name made from the security keys, a first line that stops PHP): codes are refused after 5 wrong ones as with the guard file, you get the lockout email and an alert that the counters were changed outside WordPress, and an older copy put back in the database no longer ends a lockout. The copy is removed with the lock file.
Security: while the site is locked, a deactivation that Lockdown refuses (for example wp plugin deactivate scrapelock with WP-CLI, which does not stop at the rights wp-admin checks) no longer removes the guard file, the counters copy, the early check, the pre-cache check line in wp-config.php or the scheduled events. Before, ScrapeLock stayed active but without its guard, and deleting the Lockdown data in the database then opened the lock without anyone noticing.
A site locked by 3.4.0 with "Lock without the guard file (weaker)" now gets the signed lock file on the update to 3.4.1, or in the hourly check as soon as one of its folders can be written. Site Health no longer says that no folder of wp-content can be written when one can; it names the folder and says the lock file is written there by the hourly check.
When Lockdown puts back an administration address that was changed in the database, WordPress no longer emails the planted address that the address "was changed" (which named the genuine one).
Fix: on multisite, Lockdown codes could answer "Another code was being checked at the same moment" forever once the network's table held two copies of the code-check lock (two first code checks at the same moment, or a copy added by someone with database access). Unlocking with a correct code works again; only the oldest copy is used.
Fix: on multisite databases that enforce ONLY_FULL_GROUP_BY, the Lockdown tab showed a wrong site count for the network snapshot.
Fix: after a plugin update, a second visitor request arriving at the same moment could run the upgrade routine again.
Security (WooCommerce): the long product description is now also emptied for visitors in the Store API when the request asks for only some fields (?_fields=description) and when the route is written in other letter case (/wc/Store/v1/products), which WordPress also accepts.
Security (WooCommerce): always-blocked IPs, banned IPs and blocked bots can no longer use the Store API with POST (adding items to a cart and reading the product data back, creating carts or checkouts). These writes still never count toward a limit, and other REST writes (forms, payment webhooks) are not checked, as before.
Fix (WooCommerce): the pre-cache check no longer counts the cart, checkout and My account pages (and the pages below them, such as "Order received" and My account > Orders) toward the page limit, as the normal check already did. In Emergency Mode a shopper could be limited, and then banned, while checking out. Bans and the block list still apply to these pages.
Security: a private URL given as a query on the homepage (https://example.com/?feed=skroutz) now also protects the same feed at /index.php?feed=skroutz and at its pretty addresses (/feed/skroutz/, /shop/feed/skroutz/ and the like).
Security (Cloudflare): with "Real visitor IP" left at the default behind Cloudflare, the pre-cache check now reads the visitor's address from CF-Connecting-IP, as the normal check does. Before, it saw the Cloudflare server as the visitor and let banned and blocked visitors get cached pages.
Security (Cloudflare): a Cloudflare address given as the visitor in CF-Connecting-IP (for example a Cloudflare Worker that a scraper rents) is no longer treated as the Cloudflare server itself by the early check and the pre-cache check: it can be blocked, banned and limited like any other address there too.
Fix: deleting ScrapeLock now removes the blocks still left at Cloudflare or Bunny CDN, as intended. Before, the last removal pass failed silently, and those blocks stayed at the CDN for good.
Blocking at the CDN: when Cloudflare asks to slow down, ScrapeLock now waits the full 5 minutes (or longer, if Cloudflare says so) even when new bans come in meanwhile, and it makes at most 300 API calls in any 5 minutes, well inside Cloudflare's limit, which is shared with your dashboard and other tools.
Blocking at the CDN: a Cloudflare token that is malformed or mistyped (or a Global API Key pasted as a token) is now treated as a refused token: blocking stops and waits for a working token, and the bans are blocked once it works, instead of being given up one by one. A Global API Key is named as such in the message.
Blocking at the CDN: saving a Cloudflare token now also makes one test block (added, found and removed again), so a token that can only read the rules is refused with a message that names the permission it needs.
Blocking at the CDN: an IPv6 ban of a network size Cloudflare does not accept (filter pncp_ipv6_prefix other than 48, 64 or 128) is blocked as the nearest larger network Cloudflare accepts (/48 or /64).
Blocking at the CDN: Googlebot and Bingbot addresses are never sent to the CDN as blocks, also while their official lists are not downloaded yet.
Blocking at the CDN: ScrapeLock's own Cloudflare rules are recognised more reliably (an IPv6 address written back by Cloudflare in another spelling, more than one page of rules), and rules are removed with a JSON body, as Cloudflare's API description asks.
Cloudflare rules (Server rules tab): the rate limiting rule now comes in three variants, for the Free plan, for Pro and Business, and for Enterprise, because Cloudflare allows fewer fields on the smaller plans (the old rule could only be created on Enterprise).
Cloudflare rules: no generated expression is longer than Cloudflare's 4,096 characters any more. A long list of allowed sites for hotlinking lists fewer subdomains (at the end only the site itself), and a long list of always-allowed User-Agents becomes a Skip rule of its own before the bot rules instead of being repeated in each of them.
Cloudflare rules: backslashes and quotes in the bot list, the always-allowed User-Agents and the hotlink domains are now escaped, so the expressions stay valid.

Older versions The changes of 3.4.0 and earlier are in changelog.txt in the plugin folder.

ScrapeLock – Content & AI Bot Protection

标签

下载

详情介绍:

安装:

屏幕截图:

常见问题:

更新日志: