Ⅰ php，網站製作許可權問題，怎樣設置許可權
資料庫不能執行，和文件許可權沒有關系，你應該檢查一下資料庫伺服器是否允許訪問，這個網上很多我就不敘述了。
如果是需要在WEB伺服器執行本地操作，那你需要給這些文件增加許可權，並不需要所有的都增加，比如我的網站，所有的文件操作都用一個類，所以我只需要把這一個文件設置為777就可以，其他的PHP文件調用即可完成操作
Ⅱ web前後端分離怎麼做許可權控制
許可權的設計中比較常見的就是RBAC基於角色的訪問控制,基本思想是，對系統操作的各種許可權不是直接授予具體的用戶，而是在用戶集合與許可權集合之間建立一個角色集合。每一種角色對應一組相應的許可權。
Ⅲ php怎麼進行前後端分離
可以考慮使用基於MVC的框架,比方說codeigniter, cakephp或者zend等.
後端的東西都放在C(Controller 控制器)和M(Model 模型)里,而前端則放在V(View 視圖)裡面
Ⅳ 如何通過nodejs來實現php的前後端分離
概括起來兩個方法吧。方法一$string = '';$string = preg_replace('/[abc]+/i','',$string);方法二把字元串轉化成數組$arr = str_split($string);foreach( $arr as $key => $value ){ if( in_array($value,array('a','b','c')) ){ unset($arr[$key]); }}$string = implode('',$arr);強烈推薦方法一，方法二不支持字元串中有中文。
如果樓主還不懂就去後盾人那學習吧，我聽說他們在搞實訓班培訓的活動學費九折還包住宿
Ⅳ php、HTML、網頁設計，如何設定許可權
比如你登錄後存儲用戶名是用session， 而且鍵名是user
那麼
在網頁2頭部加上如下代碼：
<?php
session_start();
if($_SESSION['user']!='bc'){
echo'<script>alert("無許可權");</script>';
die;
}
其他的同理！
當然， 具體項目這樣做的話， 肯定是不現實的， 那麼多用戶， 都用用戶名來判斷的話， 會整死人的！
所以， 我這個代碼也只是跟著你的思路走而已！
建議： 資料庫再增加一個欄位， 用於記錄該用戶許可權
登錄成功後， 同時取出該用戶的許可權欄位值，並進行儲存（ 比如session ）
然後在每個頁面用許可權欄位來進行判斷！
Ⅵ php實現代碼分離，用什麼框架
一個優秀的WEB架構，必定會應用一些分層設計的思想，這樣可以讓系統開發起來更靈活，同時後期維護也比較方便。本文作者麥舒設計了一個前端與後端分離的架構，原文分享如下：
看了《系統架構：Web應用架構的新趨勢—前端和後端分離的一點想法》 這篇文章，對前端與後端的分離非常認同，這樣做對於系統的維護是有相當大的好處的。正好自己也設計了一個這樣的系統，於是把它拿出來，和大家討論一下。這個架構，與其說是想出來，還不如說是我做系統總結出來的最佳實踐。
我們做的系統，前端的頁面基本都是使用 JavaScript 的富戶端頁面，主要應用的框架用，jquery、jquery ui、knockout js、Durandal、另外，還有自己封裝的一些 UI 組件，後端的主要採用到的技術有 OData、MVC、Linq to SQL 以及自己寫的一個許可權管理組件，資料庫採用的是 SQL Server 2005。
下面向大家介紹一下各模塊的功能以及其劃分的目的，我們先從用戶界面看起吧
一、關於前端的 dataProvider
簡單點說，就是一個給界面調用的數據訪問層，很多人都人這樣的疑問，在這里加一個數據訪問層，是不是多餘？只要你做的前端，你都會碰到下面這些問題：
1、一個產品或者項目，前端與後端是同時進行了，這時候，根本沒有後端的介面，甚至可以說，連個介面的定義都沒有。作為前端開發人員，你如何去開展自己的工作？
2、作為前端開發人員，你有沒有碰到，因為後端的介面掛掉，導致你的工作沒法繼續做下去的情形？
3、作為前端開發人員，往往免不了要和第三方的介面進行對接，你有沒有碰到過，和你做對接的人員，突然因為項目緊，被抽走了，留給你的只有一堆需要傳N個參數，傳了後接著出「對象為空」的異常呢？你根本不知道哪裡參數傳錯了。面對這些介面，你除了破口大罵，得不到任何幫助。
4、作為前端開發人員，你有沒有試過，你向後端的開發組，要一個介面，他們需要討論個幾天，然後再花幾天才能給你，給你之後，還不能用，又得再花幾天時間調試呢？
如果你向我一樣，都曾經都碰過這些問題，你就不會懷疑這個 dataProvider 存在的必要了，有了這個 dataProvider，可以最大減少後端介面對前端開發的影響。下面是一個 dataProvider 的實例：
var dataProvider = (function () {
var fakeProvider = {
countries: new Countries()
};
var realProvider = {
countries: new JData.WebDataSource()
};
//下面的介面，根據情況二選一
return fakeProvider; //這個是假的 dataProvider，從本地讀
return realProvider; //這個是真正 dataProvider，從介面讀
})();
從上面可以看出來，這個 dataProvider 使用了工廠模式來創建，它有兩個實例，fakeProvider和realProvider，fakeProvider是用來提供一些模擬數據，而realProvider提供從介面讀取出來的數據。當沒有介面，或者介面掛掉，我們可以先從 fakeProvider 來讀取數據。等介面好了，切換到 realProvider 。
二、關於用戶界面輸入的驗證
1、數據的驗證。用戶在界面輸入數據後，接著調用 dataProvider 里的介面對數據進行處理，但是在向服務端提交之前，得先對數據進行驗證。那個這個驗證如何進行呢？dataProvider先從服務端獲實體的描述信息，這些描述包括但不限於：主外鍵、屬性的驗證信息（比如是否可空），當然，這個實體信息是可以緩存起來，以便重用的。然後 dataProvider 再根據這個描述信息來對數據進行驗證。
2、錯誤信息的顯示
當驗證到某一個屬性不合法，驗證信息的模塊就在頁面查找出對應輸入控制項，它是怎麼查找的呢？比如說，Contry 的 Name 輸入為空是不可以的。那它就先查找 id 為Coutry的元素，然後再Coutry元素下面再找id 或者 name 為 Name 的控制項，如果找不到則直接彈窗顯示錯誤信息。例如：
<form id="Country">
<input name="Name"/>
</form>
三、關於後端使用 OData
1、作為後端開發人員，你有沒有碰到過這種前端開發人員，今天讓你加一個欄位，好，加了，然後打包發布。明天又讓你加一個欄位。後天突然又說，前兩天加的欄位，不需要，你會不會有種想喊「操」的沖動？
2、作為後端開發員員，你有沒有碰到過這種前端開發人員，今天跟你說介面不夠用，要加個 GetUserByName 的方法，明天又說，還得加個 GetUserByEmail 的方法？然後，過了一段時間，你發現介面越來越多，維護的模塊越來越癰腫，並且這些介面，你只敢加，不敢刪除。因為，你根本不知道這些，有哪個不用的，你跑去問前端，他也回答不出來。所以一些介面哪怕是沒用的，也只能永遠系統里，直到它生命周期的結束。
如果你也碰到類似於我這種煩惱，使用 OData 也許是一個不錯的選擇，把查詢的許可權都開發給前端的開發人員，他愛怎麼查就怎麼查，都由它去。
四、關於後端使用MVC
我們的系統，使用MVC都是用來處理從前端提交上來的數據的，使用它主要是開發人員都熟悉MVC，然後MVC再調用業務層代碼，同時，還需要處理:
1、對提交上來的數據進行驗證
2、處理系統的異常，包括對異常進行重新的包裝，再傳回到客戶端，以便於客戶端的處理。對異常的信息進行記錄。
五、數據訪問層
關於數據訪問層，在我們的系統里實際是一個 ORM 的包裝器（ORM Wrapper），你在對 ORM 裹上一層外衣。目的在於：
1、對數據進行攔截。例如：有些數據，只對某個角色的開發。數據訪問層需要對根據過濾條件，然後再結合查詢條件，重新生成SQL。
2、對數據假刪除的處理。見過很多系統，都是把刪除放到業務層來進行的，其實這是不適合的，從業務的角度來說，關心的是刪除，在執行刪除後，這條數據從我眼前消失就可以了。至真刪除還是假刪除，這與我無關。數據訪問層，要做的就是這工作，它可以數據在真刪除與假刪除之間進行切換，只要配置一下，就可以把真刪除變成假刪除（其實就是把Delete操作變成Update操作），使得進行業務開發人員，不用再關心數據的真假刪除。
3、對數據進行跟蹤、備份。你肯定碰到過這么一種需要，需要記下來，每一次的更新操作的時間，以及更新了些什麼內容。對於刪除的數據，能夠把它還原回來。數據訪問層，通過對 ORM進行包裝，完全可以記錄下每一次更新、刪除這些操作，然後記錄下來即可。當然，這些需求利用數據提供的功能也是可以實現的，不在討論的范圍內。
Ⅶ 大佬們tp框架下php怎麼實現前後端分離
不載入模板 只做介面 數據通過$this->ajaxrerturn(); 返回給請求者 前端所有數據通過ajax或者使用vue等數據綁定類的框架 通過js把獲取到的數據渲染到頁面 這樣前端就不會有後端代碼 這就是前後端分離