README

此扩展将不再维护

在此处寻找替代方案 https://github.com/b13/trusted-url-params（感谢来自 b13 GmbH 的 Benni Mack）

它做什么？

此扩展为 typolink.addQueryString 设置添加了两个新选项。这些新选项允许定义将传递给新创建的 typolink 的哪些查询参数。

第一个选项是 typolink.addQueryString.include（字符串，以逗号分隔 - 默认为空）。所有不在该列表上的查询参数将不会传递给新创建的 typolink。

第二个选项是 typolink.addQueryString.includePluginsNamespaces（布尔值 - 默认设置为 true）。如果启用，则所有不符合 Extbase 插件命名空间第一级的查询参数将不会传递给新创建的 typolink。

在后台，这两个选项都会检查 typolink.addQueryString.include、typolink.addQueryString.includePluginsNamespaces 中不存在的所有查询参数，如果存在，则将它们添加到 addQueryString.exclude 列表。

如果您不确定是否需要这些选项，请阅读背景和 addQueryString 的洪水问题。

由于默认启用 addQueryString.includePluginsNamespaces，因此在此扩展安装后，您无需更改您的 TypoScript 代码。您将默认安全免受洪水攻击！

安装

使用 composer 或通过扩展管理器下载。
```
composer require sourcebroker/urlguard
```
转到扩展管理器，找到 Urlguard，选择选项并设置 enableXclassForContentObjectRenderer。
清除 TYPO3 前端缓存。在浏览器中打开链接 https://www.example.com/?asd=1 并查找由语言菜单构建的链接。您不应该看到类似 ?asd=1&cHash=1234567890 的链接。如果您仍然看到 ?asd=1&cHash=1234567890，则表示 ext:urlguard 未能正常工作。在这种情况下，请查看下面的注释。

注意！可能发生的情况是，您已安装的某个扩展已覆盖了类 \TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer。在这种情况下，您可能期望 urlguard 无法工作，或者覆盖类 ContentObjectRenderer 的第二个扩展可能无法工作。这取决于哪个扩展最后加载 - 最后一个加载的覆盖。如果您遇到这种情况，则可以将 ext:urlguard 需要的补丁直接应用到核心类 ContentObjectRenderer。在 Resources/Private/Patches 中查找补丁，并手动或自动使用 composer 包 cweagans/composer-patches 应用它们。

注意！对于 TYPO3 6.2，您可以从 Resources/Private/Patches/ContentObjectRenderer_TYPO3_6.2.patch 应用补丁。

背景

通常在构建语言菜单（或页面浏览）时，您希望使用 typolink.addQueryString 传递查询中设置的参数，以确保这些参数在其他语言或页面浏览器中的下一页中保持一致。

让我们用一个例子来说明。用户请求的链接是新闻单页的链接：https://www.example.com/?id=10&tx_news_pi[news]=15&cHash=1234567890

当TYPO3开始生成语言菜单时，它将添加L参数来构建以下链接

https://www.example.com/?id=10&id=10&tx_news_pi[news]=15&L=1&cHash=1234567890
https://www.example.com/?id=10&tx_news_pi[news]=15&L=2&cHash=1234567890
https://www.example.com/?id=10&tx_news_pi[news]=15&L=3&cHash=1234567890

这正是您所期望的！

不幸的是，现实情况是，爬虫会不断地用非常奇怪的URL参数撞击您的网站，这些参数并非来自您的应用程序。这会是什么样子呢？让我们再看一个例子——爬虫撞击您的网站：https://www.example.com/?__asd=1139234

语言菜单将构建以下链接

https://www.example.com/?__asd=1139234&L=1&cHash=1234567890
https://www.example.com/?__asd=1139234&L=2&cHash=1234567890
https://www.example.com/?__asd=1139234&L=3&cHash=1234567890

这正是您想要避免的。这种情况的缺点是什么？请参阅下一章。

添加查询字符串的洪水问题

cf_cache_pages表的洪水问题

当typolink与激活的addQueryString选项一起使用时，没有简单的方法可以排除所有可能的查询参数（使用typolink.addQueryString.exclude），因为我们无法预测爬虫使用的所有参数。这意味着typolink将生成包含有效cHash但包含不支持我们应用程序的爬虫参数的链接。如果后来爬虫遍历这些链接，那么这些链接中的每一个都会在cf_cache_pages表中构建一个新的缓存条目。这意味着对处理器、数据库和数据库空间的压力。

tx_realurl_urldata表的洪水（不再适用于TYPO3 9.5）

每个由typolink创建的链接都有其条目在realurl表中的tx_realurl_urldata。因为没有有效的方法可以排除所有可能的查询参数（使用typolink.addQueryString.exclude），所以这个表将被洪水，并对处理器、数据库和数据库空间造成压力。

如何防止“添加查询字符串洪水”问题？

安装ext:urlguard。默认情况下，它激活了typolink.addQueryString.includePluginsNamespaces，这将排除所有不符合Extbase插件命名空间第一层的参数。

如何在没有ext:urlguard的情况下防止“添加查询字符串洪水”问题？

TYPO3提供typolink.addQueryString.exclude，您可以在其中尝试排除在创建新的typolink时不应传递的所有参数。问题是：您无法预测爬虫使用的所有参数。

唯一的100%解决方案是不使用参数的黑名单（排除），而是使用参数的白名单（包含）。这正是ext:urlguard所做的事情。

已知问题

无。

变更日志

请参阅https://github.com/sourcebroker/urlguard/blob/master/CHANGELOG.rst

sourcebroker / urlguard

维护者

详细信息