Adding a specific code for Cloudflare check #436
Conversation
- Added a check for the "Server" header in `Classes/LinkAnalyzer.php`. - If the "Server" header contains "cloudflare", `check_status` is set to `LinkTargetResponse::RESULT_UNKNOWN` and `reasonCannotCheck` is set to `LinkTargetResponse::REASON_CANNOT_CHECK_CLOUDFLARE`. - Added a new test case in `Tests/Unit/Linktype/ExternalLinktypeTest.php` to verify the Cloudflare check. - Updated `README.md` to include the new `check_status` value.
- Added a check for the "Server" header in `Classes/LinkAnalyzer.php`. - If the "Server" header contains "cloudflare", `check_status` is set to `LinkTargetResponse::RESULT_UNKNOWN` and `reasonCannotCheck` is set to `LinkTargetResponse::REASON_CANNOT_CHECK_CLOUDFLARE`. - Added a new test case in `Tests/Unit/Linktype/ExternalLinktypeTest.php` to verify the Cloudflare check. - Updated `Documentation/Setup/ExtensionConfigurationReference.rst` to include the new `check_status` value.
- Added a check for the "Server" header in `Classes/LinkAnalyzer.php`. - If the "Server" header contains "cloudflare", `check_status` is set to `LinkTargetResponse::RESULT_UNKNOWN` and `reasonCannotCheck` is set to `LinkTargetResponse::REASON_CANNOT_CHECK_CLOUDFLARE`. - Updated the test case in `Tests/Unit/Linktype/ExternalLinktypeTest.php` to use https://www.cloudflare.com and a real RequestFactory instance. - Updated `Documentation/Setup/ExtensionConfigurationReference.rst` to include the new `check_status` value.
- Modified `Classes/LinkAnalyzer.php` to prioritize Cloudflare detection. - If the "Server" header contains "cloudflare", `check_status` is now definitively set to `LinkTargetResponse::RESULT_UNKNOWN` (5), overriding other potential statuses like 3. - This ensures that the Cloudflare-specific status is correctly recorded.
- Added 'Cloudflare' (value 5) as a check_status option in the filter dropdown. - Updated the display for items with status 5 to show 'Cloudflare link' and a cloud icon. - Reused the existing RESULT_UNKNOWN (5) constant and repurposed its meaning to Cloudflare. - Added necessary translation keys for the new labels.
|
|
||
| // Check for Cloudflare | ||
| if ($linkTargetResponse->getReasonCannotCheck() == LinkTargetResponse::REASON_CANNOT_CHECK_CLOUDFLARE) { | ||
| $linkTargetResponse->setStatus(LinkTargetResponse::RESULT_UNKNOWN); |
There was a problem hiding this comment.
I am not sure I understand what is the intention of this change.
I like the idea of the icon for cloudflare.
But I don't like the idea of introducing a new status RESULT_UNKNOWN for it. Currently, the status RESULT_CANNOT_CHECK is used, which I think makes sense: we cannot effectively currently check these kind of URLs.
Also, when I apply the patch, the behaviour does not change - it still shows this as before, which is currently intended behaviour:
In a previous change, the status was introduced which could not only be "broken" or "not broken" but also e.g. REASON_CANNOT_CHECK (as defined in LinkTargetResponse).
I already introduced code to detect Cloudflare. If correctly detected, this gets the status RESULT_CANNOT_CHECK and the reason REASON_CANNOT_CHECK_CLOUDFLARE.
I don't see an advantage in now introducing a new status RESULT_UNKNOWN.
|
In our case, hundreds of government websites use Cloudflare to protect against DDoS attacks. As a result, nearly half of the 50,000 external links lead to Cloudflare-protected sites. Currently, these links return a generic check_status = 3 ("not possible to check") in the backend. This status can be misleading, as editors may assume the link will be verified later, which is not the case. To improve clarity and support accurate reporting, we suggest assigning a specific check_status for links blocked by Cloudflare. This would allow us to clearly differentiate them from genuinely broken links and exclude them from broken link exports. |
3 participants
Feature: Add Cloudflare status and filter option
Resolves #435