php語言

當前位置 /首頁/計算機/php語言/列表

重新認識PHP框架

有很多我們已經認識和了解的東西,有時候又會帶給我們不一樣的感覺,以下是本站小編精心為大家整理的PHP框架的重新認識,從一個全新的角度來詮釋PHP框架。更多內容請關注應屆畢業生網!

重新認識PHP框架

有人認為,PHP是每次請求都要初始化資源,這個開銷非常大。由此,PHP不適合使用開發框架。對於PHP,確實沒有類的持久化,使得每次請求都要初始化資源,但是,這並不是開銷的主要問題所在。最主要的問題,是在於開發PHP框架的人,對PHP本身的特性瞭解多少。最簡單的,MVC需要檢測UA,如果使用PHP自帶的get_browser函式,那肯定是死定了。因為,使用上的方便與簡單,導致的是效能的開銷。 認為不可使用PHP開發框架的,還有的觀點是:由於需要每次請求的時候初始化整個框架。其實,這也是一種誤解。如果好好看看PHP原始碼,就會了解,PHP是按請求載入需要執行的檔案,並不是整個框架。所以,對於框架本身,哪一種框架核心程式碼時越小,效能越好。

還有觀點:由於PHP這種每請求初始化資源的機制,也造成了PHP新增跨請求的高階特性相當困難。其實,跨請求本身,要看在哪一個層面。PHP提供了各類加速的快取機制。雖然PHP的類是由於目前序列化函式仍有限制,不能持久化,但資料快取對PHP的加速是相當快的。所以,認為由於這一限制,就使得PHP 只能是一個保持在一個比較簡單的web語言上面,這無疑更是錯誤的。PHP不乏大型的高速與高效的網站。並不是這些網站底層就沒有框架。

另外,還有輕信什麼測試的結果。對於測試結果,我覺得,沒有一絲一毫的可信度。我們無法相信這些測試結果,主要原因有這麼幾個方面。其一,PHP環境配置,是不是最優化配置?第二,測試結果中所選框架,是不是最優框架?僅拿CI與CAKE兩者來說,CI的日誌,沒有多種輸出,只有檔案輸出。這對於大型網站的管理是極不方便的。但是,如果將其改用LOG4PHP,那效能上的損失將會是多少,是不可想象的。原因在於,LOG4PHP是完全照抄的Java。至於CAKE,更是完全照抄RAILS。完全不顧及PHP的效能與語言本身的特性。比如最簡單的,大量靜態方法的使用。勢必造成以空間換時間。CAKE中無處不在的靜態方法,導致了記憶體中堆積大量的類。這種以空間換時間,是速度加快了,還是效能損失了,有多少人真正系統測試過?CAKE讓RUBY的人瞭解PHP是對PHP的一個促進,同時,RAILS框架,也使得PHP框架得以注入新的血液,增加了新的開發思路。但,完全照抄是 PHP目前最大的悲劇。這個當中的經典之作:CAKE:RUBY ON RAILS, SMARTY: Java STRRUTS LOG4PHP:JAVA LOG4J,可悲的是,寫這些抄襲之作的作者,都是對PHP不太瞭解,大量照搬RUBY,JAVA中的.演算法與函式,有些可以算是翻譯,比如, LOG4PHP中的PROPERTIIES檔案的處理就是這樣,不必再舉更多的例項了。為什麼不能把JSF,或TYPESTRY也抄到PHP中,這是因為,如果沒有很好的PHP功底,這幾乎是不可能的。因為,這兩個東西,如果也是照抄過來,勢必慢如蝸牛。

再有,夢想不用PHP框架開發大型網站,肯定是錯上加錯。WORDPRESS,DISCUZ這類無框架,無架構的極端糟糕的程式碼,網上已屢見不鮮。

要訪問資料庫,最小的需求,也要把資料庫訪問封裝成一個類吧?要進行錯誤與異常管理,也需要一個類吧?如果是大型的網站,總要有錯誤日誌輸出,以方便調視與執行監視吧。所以這些,拼一下,也算是PHP開發框架呀。

看樣子,否認PHP應當有框架的人,肯定也就認定,PHP做不了大網站。或者說,認定,PHP做大網站,也是垃圾架構。這可能是太武斷了。

凡認為PHP是反框架的,實際上,是不瞭解PHP語言的一些瓶頸在何處,無法寫出高效的框架,所以,才這樣認為的。

【拓展閱讀】 PHP 安全程式設計建議

  簡介

要提供網際網路服務,當你在開發程式碼的時候必須時刻保持安全意識。可能大部分 PHP 指令碼都對安全問題都不在意,這很大程度上是因為有大量的無經驗程式設計師在使用這門語言。但是,沒有理由讓你因為對你的程式碼的不確定性而導致不一致的安全策略。當你在伺服器上放任何涉及到錢的東西時,就有可能會有人嘗試破解它。建立一個論壇程式或者任何形式的購物車,被攻擊的可能性就上升到了無窮大。

  背景

為了確保你的 web 內容安全,這裡有一些常規的安全準則:

  別相信表單

攻擊表單很簡單。通過使用一個簡單的 JavaScript 技巧,你可以限制你的表單只允許在評分域中填寫 1 到 5 的數字。如果有人關閉了他們瀏覽器的 JavaScript 功能或者提交自定義的表單資料,你客戶端的驗證就失敗了。

使用者主要通過表單引數和你的指令碼互動,因此他們是最大的安全風險。你應該學到什麼呢?在 PHP 指令碼中,總是要驗證 傳遞給任何 PHP 指令碼的資料。在本文中,我們向你演示瞭如何分析和防範跨站指令碼(XSS)攻擊,它可能會劫持使用者憑據(甚至更嚴重)。你也會看到如何防止會玷汙或毀壞你資料的 MySQL 注入攻擊。

 別相信使用者

假定你網站獲取的每一份資料都充滿了有害的程式碼。清理每一部分,即便你相信沒有人會嘗試攻擊你的站點。

  關閉全域性變數

你可能會有的最大安全漏洞是啟用了 register_globals 配置引數。幸運的是,PHP 4.2 及以後版本預設關閉了這個配置。如果打開了 register_globals,你可以在你的 檔案中通過改變 register_globals 變數為 Off 關閉該功能:

register_globals = Off

新手程式設計師覺得註冊全域性變數很方便,但他們不會意識到這個設定有多麼危險。一個啟用了全域性變數的伺服器會自動為全域性變數賦任何形式的引數。為了瞭解它如何工作以及為什麼有危險,讓我們來看一個例子。

假設你有一個稱為 的指令碼,它會向你的資料庫插入表單資料。初始的表單像下面這樣:

執行 的時候,啟用了註冊全域性變數的 PHP 會將該引數賦值到 $username 變數。這會比通過 $_POST['username'] 或 $_GET['username'] 訪問它節省擊鍵次數。不幸的是,這也會給你留下安全問題,因為 PHP 會設定該變數的值為通過 GET 或 POST 的引數傳送到指令碼的任何值,如果你沒有顯示地初始化該變數並且你不希望任何人去操作它,這就會有一個大問題。

看下面的指令碼,假如 $authorized 變數的值為 true,它會給使用者顯示通過驗證的資料。正常情況下,只有當用戶正確通過了這個假想的 authenticated_user() 函式驗證,$authorized 變數的值才會被設定為真。但是如果你啟用了 register_globals,任何人都可以傳送一個 GET 引數,例如 authorized=1 去覆蓋它:

// Define $authorized = true only if user is authenticated

if (authenticated_user()) {

$authorized = true;

}

?>

這個故事的寓意是,你應該從預定義的伺服器變數中獲取表單資料。所有通過 post 表單傳遞到你 web 頁面的資料都會自動儲存到一個稱為 $_POST 的大陣列中,所有的 GET 資料都儲存在 $_GET 大陣列中。檔案上傳資訊儲存在一個稱為 $_FILES 的特殊資料中。另外,還有一個稱為 $_REQUEST 的複合變數。

要從一個 POST 方法表單中訪問 username 欄位,可以使用 $_POST['username']。如果 username 在 URL 中就使用 $_GET['username']。如果你不確定值來自哪裡,用 $_REQUEST['username']。

$post_value = $_POST['post_value'];

$get_value = $_GET['get_value'];

$some_variable = $_REQUEST['some_value'];

?>

$_REQUEST 是 $_GET、$_POST、和 $_COOKIE 陣列的結合。如果你有兩個或多個值有相同的引數名稱,注意 PHP 會使用哪個。預設的順序是 cookie、POST、然後是 GET。

  推薦安全配置選項

這裡有幾個會影響安全功能的 PHP 配置設定。下面是一些顯然應該用於生產伺服器的:

register_globals 設定為 off

safe_mode 設定為 off

error_reporting 設定為 off。如果出現錯誤了,這會向用戶瀏覽器傳送可見的錯誤報告資訊。對於生產伺服器,使用錯誤日誌代替。開發伺服器如果在防火牆後面就可以啟用錯誤日誌。(LCTT 譯註:此處據原文邏輯和常識,應該是“開發伺服器如果在防火牆後面就可以啟用錯誤報告,即 on。”)

停用這些函式:system()、exec()、passthru()、shell_exec()、proc_open()、和 popen()。

open_basedir 為 /tmp(以便儲存會話資訊)目錄和 web 根目錄,以便指令碼不能訪問這些選定區域外的檔案。

expose_php 設定為 off。該功能會向 Apache 頭新增包含版本號的 PHP 簽名。

allow_url_fopen 設定為 off。如果你能夠注意你程式碼中訪問檔案的方式-也就是你驗證所有輸入引數,這並不嚴格需要。

allow_url_include 設定為 off。對於任何人來說,實在沒有明智的理由會想要訪問通過 HTTP 包含的檔案。

一般來說,如果你發現想要使用這些功能的程式碼,你就不應該相信它。尤其要小心會使用類似 system() 函式的程式碼-它幾乎肯定有缺陷。

啟用了這些設定後,讓我們來看看一些特定的攻擊以及能幫助你保護你伺服器的方法。

TAG標籤:框架 重新認識 PHP #