自我更新 PHP+MySQL 应用程序的最佳实践是什么？答案

【问题标题】：What are best practices for self-updating PHP+MySQL applications?自我更新 PHP+MySQL 应用程序的最佳实践是什么？
【发布时间】：2010-10-17 22:49:02
【问题描述】：

现在，桌面应用程序自我更新是非常标准的做法。在 Mac 上，我书中使用 Sparkle 的每个非 Apple 程序都是立竿见影的。对于 Windows 开发人员，this has already been discussed at length。我还没有找到关于自我更新网络应用程序的信息，希望您能提供帮助。

我正在构建一个旨在像 Wordpress 或 Drupal 一样安装的 Web 应用程序 - 将其解压缩到一个目录中，点击某个安装页面，然后就可以使用了。为了获得广泛的服务器兼容性，我被要求使用 PHP 和 MySQL —— 那是 **MP 吗？无论如何，它必须是广泛的跨平台。就上下文而言，这基本上是针对小型企业的统一 Web 消息传递应用程序。这不是另一个 CMS 平台，想想 webmail。

我想了解自更新网络应用程序。首先，（1）这是一个坏主意吗？从 Wordpress 2.7 开始，自动更新是一个按钮，这看起来很简单，但我可以想象有很多方法可能会变得非常非常错误。此外，Web 文件可被 Web 进程写入的想法不是安全漏洞吗？

(2) 值得开发时间吗？世界上可能有数百万个 WP 安装，因此 WP 团队花费时间来简化它可能是值得的，在全球范围内节省了数百万工时。我只能想象我的软件安装了几千次 - 构建自我升级值得投入时间，还是我可以假设足够老练的用户首先下载和安装 Web 软件可以通过升级清单？

如果这不是安全灾难或浪费时间，那么 (3) 我正在寻找以前做过的任何人的建议。您是否在数据库中保留版本表？您如何管理数据库升级？在自更新 Web 应用程序的上下文中，您使用什么方法来回滚部分升级？使用 ORM 层是否更容易或更难？您是保留版本更改的增量，还是每次都把整个事情搞砸？

感谢您对此的看法。

【问题讨论】：

我刚才问过similar question，这可能会有所帮助。
好问题。我认为自我升级不仅减少了安装时间，而且让您能够即时修复分布式安全问题。一旦发现安全漏洞，许多开源应用程序就会被大规模利用。但你是对的，有很多事情可能会出错。如果用户自定义他们的代码怎么办？

标签： php mysql security upgrade

【解决方案1】：

坦率地说，这确实取决于您的用户群。有大量的 PHP 应用程序不会自动升级。他们的用户要么有足够的技术来处理升级过程，要么就是不升级。

我打算分两步：

1) 认真问问自己，您的用户可能真正需要什么。自我更新是否会为采用提供足够的推动力来证明额外工作的合理性？如果你确信答案是肯定的，那就去做吧。

既然你在这里问，我猜你还不知道。在这种情况下，我打算执行第 2 步：

2) 发布不带该功能的 1.0 版。等待用户反馈。您的用户可能会立即要求更简单的升级过程，在这种情况下，您应该优先考虑它。或者，您可能会发现您的用户更关心其他一些功能。

在不询问用户的情况下猜测用户想要什么是一种将大量开发时间浪费在人们实际上并不需要的东西上的好方法。

【讨论】：

【解决方案2】：

我最近一直在考虑有关数据库架构更改的问题。目前我正在研究 WordPress 以了解他们如何处理版本之间的数据库更改。以下是我目前发现的：

$wp_db_version 是从 wp-includes/version.php 加载的。此变量对应于 Subversion 修订号，并在 wp-admin/includes/schema.php 更改时更新。（可能通过钩子？我不确定。）当wp-admin/admin.php 被加载时，名为db_version 的WordPress 选项会从数据库中读取。如果此数字不等于$wp_db_version，则加载wp-admin/upgrade.php。

wp-admin/includes/upgrade.php 包含一个名为dbDelta() 的函数。 dbDelta() 扫描 $wp_queries（将从头开始创建最新数据库模式的 SQL 查询字符串）并将其与数据库中的模式进行比较，根据需要更改表以使模式保持最新.

upgrade.php 然后运行一个名为upgrade_all() 的函数，如果$wp_db_version 小于目标值，则该函数运行特定的upgrade_NNN() 函数。（即upgrade_250()，如果数据库版本低于 7499，将运行 WordPress 2.5.0 升级。）这些函数中的每一个都运行自己的数据迁移和填充过程，其中一些在初始数据库设置期间被调用脚本。很好地减少了重复代码。

所以，这是一种方法。

【讨论】：

【解决方案3】：

是的，如果 PHP 在没有警告的情况下从 Internet 上的某个地方覆盖其文件，这将是一项安全功能。无法保证服务器正确连接到您的更新服务器（如果发生 DNS 中毒，它可能会下载由其他人制作的代码） - 让其他人访问您的客户端数据。因此，数字签名很重要。

用户可以通过设置 web 目录的权限来控制更新，这样 PHP 就只有对文件的读取权限——这个过程可以简单地记录在您的程序中。

还有一个问题（我真的不知道答案）：如果 PHP 当前正在使用文件，它能否覆盖它们（例如，如果 update.php 文件本身需要更新）？值得测试。

【讨论】：

【解决方案4】：

我想您已经排除了这种可能性，但您可以将其作为服务托管。（想想 wordpress.com）

【讨论】：

我完全没有排除；实际上，我们两者都想做。

【解决方案5】：

我建议您使用pear 和set up a channel 打包您的应用程序。然后，您的用户可以通过标准接口 (pear) 升级应用程序。它不是完全自动的（除非用户在 pear 上运行某种自动化），但它是标准的，因此任何系统管理员都可以维护它。

【讨论】：

【解决方案6】：

我认为您最好的选择是更新检查机制，当有更新时会提醒管理员。

正如您所提到的，存在许多潜在的安全问题。仅由于这些，我建议不要这样做。相反，请尝试创建一个相当智能的升级脚本。

【讨论】：

【解决方案7】：

仅我的 2 美分：我认为我的 CMS 中的自动自我更新应用程序存在安全漏洞，因此如果您决定编写此功能，您应该考虑实现此行为的不同级别：

自动更新
检查更新并通知
禁用

【讨论】：