2012-11-15 72 views
0

在我的一個網站中,我使用$_SERVER['REQUEST_URI']來確定未註冊的用戶是否可以看到頁面的內容。

在手動存在寫入了關於$_SERVER['REQUEST_URI']

這是爲了訪問該頁面所需的URI。例如, '/index.html'。

我的問題是,它是在客戶端訪問任何客戶端方式,例如, index.php即使$_SERVER['REQUEST_URI']包含不同的值?

我知道$_SERVER['REQUEST_URI']包含了客戶要求的網頁和服務器返回的,但如果我不問自己這些類型的問題,曾經在一段時間我不開心

也是它認爲是好的練習用這種方式使用$_SERVER['REQUEST_URI']

編輯:我包括腳本,我使用,因爲它太普通

list($c_page) = explode('.',substr($_SERVER['REQUEST_URI'],1)); 
define('C_PAGE',$c_page ?: 'index'); 
define('LOGGED',$_SESSION['user']['id'] ?: 0); 
if(in_array(C_PAGE,array('page_1','page_2','page_3')) && !LOGGED){ header('Location: login.html'); exit; } 
+0

像'/index.php?foo=bar'或'/ index.php/path_info'? –

+0

我包含了我使用的腳本,因爲它太一般了 – wlf

+2

您可能有更好的方法來建立這種訪問限制。 –

回答

0

根據服務器端的軟件包,使用此變量由webserver或fastcgi包裝器設置。

您的硬件/軟件堆棧中的URL重寫和非透明代理可以影響您在腳本中看到的值。

例如Nginx可以將/test.html中的URL重寫爲/index.php?action=test,然後將其傳遞給您的網絡服務器。用戶在您的應用程序看到/index.php?action=test時會調用/test.html

結論:REQUEST_URI是傳遞給Web服務器的URI,可用作基於URL的訪問控制的參考。

編輯:

只是爲了避免混淆,因爲我見過的其他答覆......

我瞭解你的問題: 你想請檢查是否您的當前請求,並且已經密碼授權用戶有足夠的權限訪問特定的URL。再次,是的,你可以使用請求uri作爲參考值

+0

我不知道REQUEST_URL。奇怪它沒有在這裏列出php.net/manual/en/reserved.variables.server.php雖然它在評論中提到。我剛剛在一個使用Apache作爲web服務器的網站上完成了print_r($ _ SERVER),並且REQUEST_URL不可用,我想知道它會得到多少支持? – wlf

+0

好點,由我對URI和URL的一般混淆引起的錯字,更正了我的答案,但仍然有效 –

+0

我知道,如果URL接受任何from/to,URL重寫可能是該腳本的問題。我沒有使用mod_rewrite,也沒有使用代理,這就是爲什麼我的問題是關於客戶端的,正如我所說的'以任何客戶端方式'。這仍然是最有趣的答案:) – wlf

0

就個人而言,我覺得它更可靠申報用戶的一個或多個組(班)應當具備的訪問文件,然後包含返回401錯誤的頁面(如果登錄用戶不在任何這些組中)。例如

session_start(); 
... 
$access = 'admin'; 
include 'inc/guard.php'; 

聽起來像你的情況,你想「公」和「登錄」,這是略有不同,但也覆蓋了警惕腳本的情況下。在那裏,我只是檢查$_SESSION變量是空的(我在日誌中插入東西進去):

if($access != 'public' && empty($_SESSION)) { 
    header('HTTP/1.1 401 Unauthorized', true); 
    include 'inc/login.php'; 
    exit; 
} 
1

你真的應該跟蹤他們有一個會話變量(或餅乾)入口。其中任何一個都可能被阻止......但它們更接近「萬無一失」。也就是說,任何事情都可以僞造......所以如果安全是最重要的,那麼使用組合和/或強大的獨特字符串。

+0

他沒有說他想替換用戶登錄,而不是檢查當前用戶當前URL的權限。他需要一個堅實的參考,不能被操縱的客戶端 –