2014-02-27 33 views
1

是否有可能使python成爲web服務器,並且前端是codeigniter?codeigniter作爲web和python作爲web服務

對於一些原因:

  • 數據庫的安全性 - 當你保存數據等。 codeigniter將數據傳遞給python basehttpserver /或者也許燒瓶(但我還沒有做過燒瓶之前)
  • SQL注入。

這就像是一個例子。前端codeigniter

  • 表格 - 發送數據。

後端蟒蛇Web服務

  • 接收數據 - 將作爲一個API。 python將負責在MySQLdb中保存數據。
+0

網絡服務器不處理數據庫安全。你爲什麼認爲這是一個好的設置? – Blender

+0

@Blender ..我在想那個。將數據發送到python web服務,它將作爲codeigniter的API。 – Vincent

+1

沒有理由不能這樣做,這與面向服務的體系結構或多層應用程序類似。主要要求是您定義了服務之間的良好接口,用於構建服務的語言/技術堆棧則不再相關。如果出於安全原因這樣做,那麼您還應該確保服務之間存在適當的網絡分隔(即數據庫位於防火牆之後並與Internet隔離)。這也可以是一種提高可伸縮性的方式,因爲第二層可以有額外的負載平衡。 – Tim

回答

3

理論上我不明白爲什麼這是不可能的。

您可以使用codeigniter輕鬆編寫Web應用程序,並讓控制器只將數據傳遞給基於python的Web服務。如果您對完全分離的前端/後端感興趣,則還可以在CI程序中的數據輸入工具和Python中的持久性Web服務之間使用排隊層(例如RabbitMQ)。

這就是說,我不清楚你爲什麼想要。 CodeIgniter是PHP,它包含一些非常優秀的數據建模組件,它們完全集成到整個框架中。長話短說,如果您使用的是CodeIgniter,只需將它連接到MySQL併爲您執行數據持久性。

同樣,如果您希望在Python中編寫持久性代碼,爲什麼不使用Django?它是一個完全實現的Python Web框架,並且還具有優秀的ORM和對MySQL的支持。

我真的不明白這兩種技術如何爲您提供明確的好處,前提是它們都正確使用,用於數據庫安全。兩者都有的「清洗」用戶提供的數據,以防止SQL注入(notes for Djangonotes for CodeIgniter)內置方法

有StackOverflow上許許多多其他的職位涉及防止SQL注入使用CodeIgniter和其他框架。只需使用python,或將前端和後端解耦,就不會爲您提供任何額外的安全或保護保證。要做到這一點的唯一方法就是小心地構建與數據庫的交互,使用您正在使用的任何框架提供的所有工具,或者在沒有可用的情況下創建它們的等價物(或切換到更好的工具集)。

編輯 - 擴張

基於以上我的評論想通它實際上是值得寫一點點更多的潛在優勢和解耦基礎設施的真正的挑戰。

原則上,很容易將前端與更獨立的後端分離。您可以利用Django或可能的CodeIgniter(儘管我沒有親眼看到它在CI中完成),只是在現有的模型基礎結構中,但是隻在前端處理內存中的模型對象,並擴展現有的ORM功能使用後端服務實際存儲和檢索持久層(數據庫)中的數據。

實際上,這可以成爲相當多的工作來做正確的事情。爲了獲得你想要的安全優勢,你的分離後端需要處理前端,就好像它原則上是「敵對的」,或者至少是不可信的。所以,確保你實現了一個前端可靠地向後端認證的方法。確保前端和後端之間所有流量均使用SSL。仔細考慮你的服務架構(在你的後端邏輯之前的SOA層),並確保你的API在可能的情況下是MECE(互斥,集體窮舉)。

我確定我錯過了一些基本原理,但最近參與了這些系統的設計和構建,我可以向你保證複雜性可以很快爆炸,所以謹慎的架構紀律和遵守MECE和MVP(最低可行產品)都非常關鍵。如果解耦的基礎架構能夠滿足需求,那麼它可以是一個驚人的終端產品,並且在使用它的情況下,它非常有效。儘管如此,它並不是一種通用的方式,希望這裏的一些額外描述可以幫助您做出更明智的選擇。

希望這有助於完成主題答案。基本原則:設計你所需要的。不要把複雜和安全混爲一談。簡單可以是安全的,也可以是複雜的,但複雜性爲難以插入的安全漏洞創造了空間,而簡單的看似簡單卻給人一種安全的幻覺。沒有辦法可以保證積極的結果,所以不要試圖偷工減料;花盡可能多的時間在研究和設計上,以儘量減少時間構建,重構和修復。

+1

對於簡單的Web應用程序,您的建議是正確的,但是與前端應用程序隔離的第二層是提供額外安全性的常用方式,尤其是在數據庫包含需要保護的敏感客戶數據的情況下。這在您可能沒有或不想從DMZ直接訪問數據庫的系統中也很常見。 – Tim

+0

當然,所有示例都是上下文相關的。我認爲核心原則是根據您的真實需求選擇您的技術堆棧,但不要成爲脫鉤提升安全性的錯誤預期的受害者。它沒有。事實上,天真的解耦大大增加了潛在的安全漏洞。例如,DMZ和非DMZ系統之間的流量可能被不恰當地保護,或者假設由於安全數據庫「不」可從外部訪問,所以用戶帳戶不需要密切管理並且不需要安全卷。這些是公共設計失敗時,解耦。 – ProgrammerDan