从（PHP）流包装错误消息中删除密码？答案

【问题标题】：Remove passwords from (PHP) stream wrapper error messages?从（PHP）流包装错误消息中删除密码？
【发布时间】：2017-04-08 19:04:41
【问题描述】：

在生产服务器上，错误输出肯定是例行公事。尽管如此，即使在我的开发屏幕上看到这样的错误消息，我还是会感到紧张：

stat(): stat failed for ftp://user:pass@127.0.0.1:21/dir-de-nada

这是在我围绕ftp:// 流编写的一个类的上下文中。当然 PHP 不能从任意位置过滤掉密码。但在这种情况下（与 URL 包装器和其他任何地方一样），密码的存在是标准且显而易见的。

我已经发现了错误。但是，我发现自己想知道是否需要自己解决这些问题，只是为了在所有情况下都安全，或者是否有一种方法可以让 PHP 自动全局执行。（那是这里的问题。）我猜不是，但在这里折腾一个探针没有害处。

至于我担心的是，它只在我的开发屏幕上。 但是错误报告也与站点管理员等相关，他们可能不需要知道 FTP 密码。将 FTP 密码脱口而出到错误日志中并不是什么大问题，但对于保存到数据库等中的报告来说——出于显而易见的原因，我真的不希望这种信息在任何地方传播。请问预防指点？

如果有人愿意提供有关防止 PHP 在任何情况下脱口而出密码等敏感信息的相关说明，我们也欢迎。除了“不要在任何地方输出任何东西”。

编辑：更好的选项待定，我的错误和异常处理程序的消息部分现在运行：

$msg = preg_replace('#((ftp|http)://)([^@]+?)@#', '$1*:*@', $msg);

如果使用 SSH2 流，请为 ssh2\.(shell|exec|sftp|scp) 添加正则表达式以防万一。另外，如果您使用显示参数的堆栈跟踪，也要对其进行清理。

Edit2：关于使用 PHP 的 FTP 流上下文包装器的经验的一般说明。

如果有任何失败的请求，特别是执行糟糕的，给出重复的脚本超时。
流回调（在create_stream_context / $param['notification'] 中定义）主要记录空白/部分，而不是来自 FTP 服务器的完整响应。
使用流上下文的文件系统函数可能会也可能不会返回正确/一致的错误，或将任何内容记录到回调中。（如果有人想了解故障，请尽管询问。）
似乎没有持久连接的选项：即使我回收了stream_context_create 资源，PHP 也会为同一脚本中的每个 filesys 调用重新登录。

假设 FTP 流上下文对于一次性基本事务来说很好，但是对于尝试一次性做更多事情的严重否定，感觉有点像不成熟的替代品。用于文件系统功能的装备。接下来...

【问题讨论】：

【解决方案1】：

没有。

我认为在stream context 中设置用户名和密码是有争议的，但这是not an option。

您可以通过使用不使用 URI（FTP 或 Curl）的 API 来防止这种情况发生，但这确实意味着更冗长的代码。

在生产系统上禁用错误报告绝对是一项要求。但是启用您自己的错误处理程序（在开发/测试以及生产中 - 具有特定于环境的功能）提供了额外的保护层。

试图篡改输出流以控制错误消息的内容是不可能的。但这在您的错误处理程序中肯定是一个好主意。为什么要在正则表达式中硬编码方案？

#(([a-zA-Z]+)://)([^@]+?)@#

【讨论】：

使用 FTP 扩展将是另一个依赖项，唉，Curl 确实需要更多代码。此外，我希望 ftp 流包装器的性能会更好，而不是我要编写一个 Curl 版本来进行基准测试。至于正则表达式，我实际上像您为初学者所做的那样编写它（NB 需要 [a-z2.] 用于 ssh2.* 的东西）。但是由于只有三个带有密码的内置流上下文，即。 ftp、http 和 ssh2 使得匹配较少。不需要为其他流上下文清理数据？
是的，看来我正在将我的包装类移植到 FTP 和/或 Curl 毕竟，ftp:// 流包装器的性能就像陈旧的 s**t 一样（参见上面的 Edit2）。在这里，我认为这是一件漂亮而巧妙的事情。似乎该功能仍然相当不成熟，至少就 ftp:// 流而言。在一天结束时，Curl 的代码并没有那么多，而是通过几种方法来管理大量代码。可能只是直接使用 FTP 模块，至少看起来它实际上专用于与 FTP 一起正常工作吧。
我听说 Curl 应该表现得更好。据我了解，FTP 模块是在流上下文之上构建的。默认好像没有开启，所以Curl是下个版本的。