首頁 > 後端開發 > php教程 > PHP開發人員常見的另外7個錯誤

PHP開發人員常見的另外7個錯誤

Lisa Kudrow
發布: 2025-02-20 10:25:11
原創
923 人瀏覽過

7 More Mistakes Commonly Made by PHP Developers

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框架就將不存在。
  2. 只需牢記它,您就會每次編寫它都會形成眼睛反射。它只需要練習,但是它甚至是最好的開發人員,那就是1。和2。
  3. 6。太透明
  4. 說這可能引起一些爭議,但無論如何。除非您對框架的開發人員有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,這是默認情況下的工作方式,除非您放鬆這些限制。
  2. >
  3. 這些方法中的任何一種都可以完全阻止所有問題。請記住,當推動生產時,請確保您的開發配置是完全無法訪問的,或者僅適用於白色的IPS集合。

結論

您對此列表有何看法?它涵蓋了共同方面還是太深奧?您是否有一些更常見的陷阱,總共沒有提及?在下面的評論中讓我知道,如果您的建議是正確的,我們將更新帖子!

>

以上是PHP開發人員常見的另外7個錯誤的詳細內容。更多資訊請關注PHP中文網其他相關文章!

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
作者最新文章
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板