VersionOne Bugzilla 集成 "Validation Failed"
VersionOne Bugzilla Integration "Validation Failed"
我正在尝试设置 VersionOne-Bugzilla 集成工具 (https://community.versionone.com/VersionOne_Connect/Supported_Integrations/VersionOne_Integration_for_Bugzilla_5.0_and_Above)，但在尝试设置 ServiceHost 配置时遇到了一个问题。在 Bugzilla 服务设置选项卡上，我无法获得成功的验证。这是我的错误消息的图片，下面是我输入的内容：
Bugzilla URL：https://<域>:<端口>/xmlrpc.cgi
用户名：<确认的用户名（具有管理员权限 + edit/view 错误权限）>
密码：<密码>
上面的 URL（没有附加 xmlrpc）让我进入了 Bugzilla。顺便说一句，这不是新安装，我们已经使用了一段时间。我之前也使用过相同的格式并附加了 /rest 来成功调用 REST API。我还测试了使用该用户手动登录并正常运行。
在文档中，URL 示例显示附加“/rest”而不是“/xmlrpc.cgi”，这也没有验证（选中或不选中忽略证书）。直到我从 2 天前下载了最新版本并尝试使用更新版本，我才看到附加了“/xmlrpc.cgi”。在配置文件中看到这一点并在文档中看到该工具需要为 RPC 设置 Bugzilla 之后，我继续研究它，发现我在 Bugzilla 中缺少一些 RPC 模块。我安装了以下四个：
SOAP-Lite
XMLRPC-Lite
JSON-RPC
测试污染
Bugzilla 的 运行 checksetup.pl 显示找到所有 4 个。之后，我用这里的工具（https://docs.devzing.com/bugzilla-xml-rpc-client/）测试了一次版本调用，结果如下：
现在我很困惑。我已经验证用户可以访问 Bugzilla，并且我已经安装了可选的 RPC 模块 + 验证了对 Bugzilla 的 XMLRPC 调用有效，但 ServiceHost 工具仍然无法验证。我 missing/doing 哪里错了？此验证尝试是否记录在任何地方以获取更多信息？
谢谢！
更新： 在尝试使用 Fiddler 进行一些跟踪后，我调整了 Fiddler 设置以处理 HTTPS。完成后，只要 Fiddler 跟踪流量，验证就会成功。如果没有这些选项，验证仍然会失败。当我关闭 Fiddler 并尝试再次验证时，它失败了。该工具对 HTTPS 的处理似乎存在一些问题。另请注意，我确实在 URL 和 "ignore certificate" 中切换回使用“/rest”，但仅靠这些并没有解决问题，因为我之前说过我已经尝试过但没有成功唯一的解决方案。我可以对 ServiceHost 工具进行一些更改以在没有 Fiddler 的情况下正确地完成此 运行 吗？
如果您能够配置您的集成以通过 fiddler 使用，请使用它并保存您的配置。该工具显然错误地处理了您连接到 Bugzilla 实例的尝试并给出了漏报。 VersionOne.Servicehost.exe.config 的目标只是一个 xml 文件，其中包含在服务主机工具中输入的配置。
配置后，保存配置并尝试 运行 服务主机可执行文件读取文件并尝试连接到您的 Bugzilla 实例。应该 运行 可以。密切关注错误日志文件 ( servicehost.log ) 和控制台中的错误。要获得详细日志记录，请打开 VersionOne.ServiceHost.exe.config，然后找到“<"LogLevel>"Info”的两个实例并将其替换为“Debug[=21” =]”。您很少会使用配置工具。如果此解决方法还不够，代码在此处
https://github.com/versionone/VersionOne.Integration.Bugzilla
最后一点。谨防！备份您的工作配置。在某些情况下，手动破解 xml 后使用 servicehost 工具可能会覆盖您的内容。
问题最终是 OpenSSL 已过时，需要从我们旧的 0.9.8 版本升级到 1.0.1+。在 1.0.1+ 中，他们添加了对 TLS v1.1 和 v1.2 的支持。
升级非常顺利（注意这是在 Windows 服务器上）。我需要替换 2 个 DLL：libeay32 和 ssleay32，以及 Apache bin 文件夹中的 openssl 可执行文件。正如 Mark Irvin 在他的回复中所说，确保您事先备份了您将要更改的任何内容。完成后，我在尝试备份 Apache/OpenSSL 和 运行 时遇到了一个错误，那就是我缺少新版本 OpenSSL 所需的新 DLL。从 Microsoft 的站点下载并安装它后，Apache 运行 再次顺利，现在我可以在没有 Fiddler 的情况下在工具中完成与 Bugzilla 的连接。
来自telerik.com，这就是Fiddler让它工作的原因：
Running Fiddler resolves such problems because Fiddler, by default, only uses SSLv3.0 and TLSv1.0 when communicating with HTTPS servers, avoiding the compatibility problems seen on legacy servers. If your computer has the .NET Framework v4.5 installed, Fiddler v4 can be configured to attempt to use TLS/1.1+ which will lead to the same connection failure seen when Fiddler wasn’t present.
To resolve this issue, either disable TLS/1.1+ on the client, or better yet, nag the server operator to upgrade their software to support the TLS standard.
我正在尝试设置 VersionOne-Bugzilla 集成工具 (https://community.versionone.com/VersionOne_Connect/Supported_Integrations/VersionOne_Integration_for_Bugzilla_5.0_and_Above)，但在尝试设置 ServiceHost 配置时遇到了一个问题。在 Bugzilla 服务设置选项卡上，我无法获得成功的验证。这是我的错误消息的图片，下面是我输入的内容：
Bugzilla URL：https://<域>:<端口>/xmlrpc.cgi
用户名：<确认的用户名（具有管理员权限 + edit/view 错误权限）>
密码：<密码>
上面的 URL（没有附加 xmlrpc）让我进入了 Bugzilla。顺便说一句，这不是新安装，我们已经使用了一段时间。我之前也使用过相同的格式并附加了 /rest 来成功调用 REST API。我还测试了使用该用户手动登录并正常运行。 在文档中，URL 示例显示附加“/rest”而不是“/xmlrpc.cgi”，这也没有验证（选中或不选中忽略证书）。直到我从 2 天前下载了最新版本并尝试使用更新版本，我才看到附加了“/xmlrpc.cgi”。在配置文件中看到这一点并在文档中看到该工具需要为 RPC 设置 Bugzilla 之后，我继续研究它，发现我在 Bugzilla 中缺少一些 RPC 模块。我安装了以下四个：
SOAP-Lite
XMLRPC-Lite
JSON-RPC
测试污染
Bugzilla 的运行 checksetup.pl 显示找到所有 4 个。之后，我用这里的工具（https://docs.devzing.com/bugzilla-xml-rpc-client/）测试了一次版本调用，结果如下：
现在我很困惑。我已经验证用户可以访问 Bugzilla，并且我已经安装了可选的 RPC 模块 + 验证了对 Bugzilla 的 XMLRPC 调用有效，但 ServiceHost 工具仍然无法验证。我 missing/doing 哪里错了？此验证尝试是否记录在任何地方以获取更多信息？ 谢谢！
更新： 在尝试使用 Fiddler 进行一些跟踪后，我调整了 Fiddler 设置以处理 HTTPS。完成后，只要 Fiddler 跟踪流量，验证就会成功。如果没有这些选项，验证仍然会失败。当我关闭 Fiddler 并尝试再次验证时，它失败了。该工具对 HTTPS 的处理似乎存在一些问题。另请注意，我确实在 URL 和 "ignore certificate" 中切换回使用“/rest”，但仅靠这些并没有解决问题，因为我之前说过我已经尝试过但没有成功唯一的解决方案。我可以对 ServiceHost 工具进行一些更改以在没有 Fiddler 的情况下正确地完成此 运行 吗？
如果您能够配置您的集成以通过 fiddler 使用，请使用它并保存您的配置。该工具显然错误地处理了您连接到 Bugzilla 实例的尝试并给出了漏报。 VersionOne.Servicehost.exe.config 的目标只是一个 xml 文件，其中包含在服务主机工具中输入的配置。
配置后，保存配置并尝试 运行 服务主机可执行文件读取文件并尝试连接到您的 Bugzilla 实例。应该 运行 可以。密切关注错误日志文件 ( servicehost.log ) 和控制台中的错误。要获得详细日志记录，请打开 VersionOne.ServiceHost.exe.config，然后找到“<"LogLevel>"Info”的两个实例并将其替换为“Debug[=21” =]”。您很少会使用配置工具。如果此解决方法还不够，代码在此处
https://github.com/versionone/VersionOne.Integration.Bugzilla
最后一点。谨防！备份您的工作配置。在某些情况下，手动破解 xml 后使用 servicehost 工具可能会覆盖您的内容。
问题最终是 OpenSSL 已过时，需要从我们旧的 0.9.8 版本升级到 1.0.1+。在 1.0.1+ 中，他们添加了对 TLS v1.1 和 v1.2 的支持。
升级非常顺利（注意这是在 Windows 服务器上）。我需要替换 2 个 DLL：libeay32 和 ssleay32，以及 Apache bin 文件夹中的 openssl 可执行文件。正如 Mark Irvin 在他的回复中所说，确保您事先备份了您将要更改的任何内容。完成后，我在尝试备份 Apache/OpenSSL 和 运行 时遇到了一个错误，那就是我缺少新版本 OpenSSL 所需的新 DLL。从 Microsoft 的站点下载并安装它后，Apache 运行 再次顺利，现在我可以在没有 Fiddler 的情况下在工具中完成与 Bugzilla 的连接。
来自telerik.com，这就是Fiddler让它工作的原因：
Running Fiddler resolves such problems because Fiddler, by default, only uses SSLv3.0 and TLSv1.0 when communicating with HTTPS servers, avoiding the compatibility problems seen on legacy servers. If your computer has the .NET Framework v4.5 installed, Fiddler v4 can be configured to attempt to use TLS/1.1+ which will lead to the same connection failure seen when Fiddler wasn’t present.
To resolve this issue, either disable TLS/1.1+ on the client, or better yet, nag the server operator to upgrade their software to support the TLS standard.