PHP开发人员常见的另外7个错误

自由市场的Toptal发表了大约10个最常见的错误PHP程序员犯下的帖子。该列表并不详尽，但写得很好，并指出了一些非常有趣的陷阱，即使我个人不会列出错误很常见。

>我鼓励您对其进行彻底的阅读 - 它具有您应该意识到的一些真正有价值的信息 - 尤其是前八个。几天前，安娜·菲利娜（Anna Filina）用七个新条目扩展了名单。虽然较不具体和普遍，但她的观点仍然具有重量，并且在开发时应考虑。

钥匙要点

>避免在SQL数据库中使用已弃用的MySQL扩展名，因为它是不安全的，不可靠的，并且缺乏对SSL和现代MySQL功能的支持。相反，选择诸如Mysqli或PDO之类的替代方案，这些替代方案提供更好的安全性和更多功能。

>避免使用 @ Operator抑制代码中的错误。而是允许记录错误并通过修复代码来解决这些错误。这有助于保持应用程序的完整性，并防止问题被忽略或忽视。

>要谨慎透露有关后端设置的太多信息，尤其是在使用已知框架的情况下。如果发现该框架中的安全漏洞，则可以将您的应用程序暴露于潜在的攻击中。另外，请记住要在推动生产以防止未经授权的访问时删除开发配置。>
7个错误PHP开发人员通常会造成
>我被Toptal的某人要求我查看他们的清单并有可能做出贡献，我们在社交网络上的一些追随者也对看到清单的兴趣也继续，所以我想借此机会来在此列表中添加一些我自己的条目，我需要一再警告我的团队成员或追随者。
• 1。使用mysql扩展

这个消息很古老，但是遗忘了事实的开发人员的数量令人担忧。当使用SQL数据库，特别是MySQL时，太多的开发人员仍然选择MySQL扩展名。 MySQL扩展已正式贬值。它不安全，不可靠，不支持SSL，并且缺少一些现代的MySQL功能。它还生成不破坏您的应用程序的折旧通知，它们只是出现在您的应用程序的顶部。有趣的是，这意味着也可以简单地为所有使用此不安全设置的网站进行Google，而简单地寻求此设置。这些应用程序因这种混乱而暴露的伤害世界令人震惊。

而不是使用mysql，而是选择一种替代方法：mysqli或pdo。例如，使用mysqli几乎与将字母“ i”添加到API呼叫的末端一样简单：>

<span>$c = mysql_connect("host", "user", "pass");
</span><span>mysql_select_db("database");
</span><span>$result = mysql_query("SELECT * FROM posts LIMIT 1");
</span><span>$row = mysql_fetch_assoc($result);</span>

vs

<span>$mysqli = new mysqli("host", "user", "pass", "database");
</span><span>$result = $mysqli->query("SELECT * FROM posts LIMIT 1");
</span><span>$row = $result->fetch_assoc();</span>

这就是使设置变得更加安全所需的全部。

> 不过，您应该选择PDO。在第2点。

2。不使用PDO

不要误会我的意思，Mysqli（从字面上看）几代人都领先于古代MySQL扩展。它保持最新，安全，可靠和快速。但是，这是特定于MySQL的。相反，使用PDO将使您使用一些非常实用的面向对象的语法，并将与其他SQL数据库（如PostgreSQL，MS SQL等）一起为探戈做准备。此外，PDO将让您使用名为参数，这是一项非常有用的功能，很少有人能想象在适当地利用它后会去其他任何东西。最后但并非最不重要的一点是：您可以将获取的数据直接注入新对象，这在大型项目中是一个令人愉快的时间。

3。不重写URL

>另一个通常被忽略且易于解决的问题。像myapp.com/index.php？p = 34＆g = 24之类的URL在当今时代不可接受。由于很难编写一个良好的URL重写指南，该指南将涵盖每个服务器和框架，因此几乎每个框架都有一个指南，有关如何设置干净的URL（Laravel，Phalcon，Symfony，Symfony，Zend）和任何不'只是不值得使用 - 他们显然不在乎现代实践。

4。抑制错误

>我在上一篇文章中写了这一点，但值得一提。每当您发现自己使用 @操作员时，重新考虑并从其他角度仔细解决问题。当我说围绕应用程序功能周围的20条样板卷曲代码比单线 @ operator在其前面的一行时，请说出我的话。

>

>我通过个人实验发现，一个好的方法是我在原始帖子中提倡的方法 - 将所有通知变成致命错误。确保

没有

登录到错误日志中，因为从字面上看

> log> 比假装大便更好地通过在您的眼前握住 @ the the the the the the the the the the the。 >我们最近介绍了一些Heroku附加组件，用于生产Ready PHP应用程序，其中之一是出色的纸质编写片 - 一种附加组件，可让您将所有应用程序的错误推向其后端，以便于稍后搜索，分组和淘汰在;因此，即使确实发生了一些错误，最好让它们记录并通过修复代码来摆脱它们，而不是沉默它们并在用户面前玩愚蠢。

5。在条件下分配

>即使是经验丰富的开发人员有时会有一条手指滑动，然后写（$ condition ='value'）{而不是if（$ condition =='value'）{。我们的手会滑倒，键盘不会注册按键，我们最终会从分配实际发生的代码的另一部分粘贴 - 发生了 - 通常只有在运行应用程序时才发现。

有几种完全避免这种情况的方法：

>

使用一个体面的IDE。任何好的IDE（例如PhpStorm）都会在检测到它们时警告您。
1. 使用“ YODA条件”。您会在许多受欢迎的项目，甚至大型框架中看到这些。通过反转比较（如（例如（'value'= $条件））{）{），较弱的IDE也会注意到问题。有些人认为Yoda语法令人讨厌且毫无意义，这是一个应该没有的生命线（“对您的代码，该死更加谨慎”），但是对每个人都有自己的帮助 - 如果对某人有帮助，我全都为此。如果我们都是精英人士，那么WordPress和Zend框架就将不存在。
只需牢记它，您就会每次编写它都会形成眼睛反射。它只需要练习，但是它甚至是最好的开发人员，那就是1。和2。
6。太透明
说这可能引起一些争议，但无论如何。除非您对框架的开发人员有100％的信心，否则不经营高保罗，交通高级业务关键应用程序，否则您应该始终努力掩盖您的后端方式 - 不要广播您的应用程序基于哪个框架实际上是基于CAN的框架如果发现该框架的安全漏洞，请帮助防止攻击。例如：

如果您使用Symfony2 Translator，并且具有{_locale}参数升级的路由！ http://t.co/jihxhb8mzt - JérémyDerussé（@jderusse）2014年7月15日

在这推文中，对严重的代码注入问题的了解正在广播到公共领域。如果您在工作，并且可以在没有DevOps问题的情况下立即升级并让团队首先缩减，但是对于大多数使用Symfony的公司和公司而言，情况并非如此。即使可以通过作曲家升级Symfony（正如Ryan在下面的评论中提到的那样），但通常需要一段时间才能在具有多层环境的大型团队中获得批准。所有使用此翻译器方法声明为Symfony用户的网站是（曾经？）。

在上面的示例中使用Symfony只是一个示例。多年来，无数其他软件也出现了类似的情况。回到我仍然商业上使用Zend Framework时，我们也发生了这种情况，因此遭受了攻击。 WordPress拥有其安全性的一部分，我们知道那里的网站有多高。这些事情发生了，有时，开源和透明度并不是处理公司大部分收入来源的应用程序时的最佳方法。

7。不删除开发配置

最后但并非最不重要的一点是，应提及开发配置删除。最近（这是一个诚实的巧合，我再次在这里提到Symfony），CNET由于没有消除其开发配置而遭受了攻击。

> uhmmm no：http：//t.co/raqis1ycwq #security #symfony

- Marco pivetta（@ocromius）2014年7月15日

世界上最大的科技新闻网站之一

> CNET是基于Symfony的。众所周知，Symfony为您的应用程序提供了两个入口点：app.php和app_dev.php。通过将浏览器指向一个，您可以获得生产环境。通过指向_dev后缀的一个，您显然会获得开发版本，该版本具有调试器，敏感数据等。无论是好还是坏，都是许多讨论的主题（再次感谢Ryan指出了这一点），但是不可否认，它使一些更笨拙的开发人员对诸如CNET遭受的错误打开了错误。此外，当在app_dev上访问的任何其他URL都将重定向到其他app_dev URL。换句话说，不仅是在开发模式下启动的索引页面，而且是整个网站 - 在CNET的情况下，这是很多访问权限。

>

如果您在Twitter上进行讨论，它会非常快速地感到难过 - 甚至令人难过的是，它本来可以在第二秒的工作中避免的：>

开发人员可以从生产服务器中删除app_dev.php

1. >开发人员可以允许使用白名单的IPS访问app_dev.php，这是默认情况下的工作方式，除非您放松这些限制。
>
这些方法中的任何一种都可以完全阻止所有问题。请记住，当推动生产时，请确保您的开发配置是完全无法访问的，或者仅适用于白色的IPS集合。

结论

您对此列表有何看法？它涵盖了共同方面还是太深奥？您是否有一些更常见的陷阱，总共没有提及？在下面的评论中让我知道，如果您的建议是正确的，我们将更新帖子！

>

以上是PHP开发人员常见的另外7个错误的详细内容。更多信息请关注PHP中文网其他相关文章！