首頁猿問你能幫我理解嗎？“常見...

你能幫我理解嗎？“常見的REST錯誤：與會話無關(guān)”

源碼

函數(shù)式編程 2020-02-04 14:41:43

免責(zé)聲明：我是REST思想流派的新手，我正努力將其束縛在其中。因此，我正在閱讀此頁面Common REST Mistakes，我發(fā)現(xiàn)我對與會話無關(guān)的部分完全感到困惑。這就是頁面上所說的：客戶端無需“登錄”或“啟動連接”。HTTP驗證在每條消息上自動完成?？蛻舳藨?yīng)用程序是資源而不是服務(wù)的使用者。因此，沒有什么可登錄的！假設(shè)您正在通過REST Web服務(wù)預(yù)訂航班。您不會為服務(wù)創(chuàng)建新的“會話”連接。而是您要求“行程創(chuàng)建者對象”為您創(chuàng)建一個新的行程。您可以開始填充空白，然后在網(wǎng)絡(luò)上的其他位置獲取一些完全不同的組件來填充其他空白。沒有會話，因此在客戶端之間遷移會話狀態(tài)沒有問題。也沒有“會話親緣關(guān)系”的問題好的，我知道每條消息都會自動完成HTTP身份驗證-但是如何？用戶名/密碼是否隨每個請求一起發(fā)送？那不是增加攻擊表面積嗎？我覺得我好像迷失了一部分。有一個REST服務(wù)（例如）/session接受GET請求是否會很糟糕，您將在其中傳遞用戶名/密碼作為請求的一部分，如果身份驗證成功，則返回一個會話令牌，然后與后續(xù)請求一起傳遞？從REST的角度來看這是否有意義，還是缺少這一點？

查看完整描述

3 回答

MMTTMM

TA貢獻(xiàn)1869條經(jīng)驗獲得超4個贊

為了實現(xiàn)RESTful，每個HTTP請求應(yīng)自行攜帶足夠的信息，以便其接收者對其進(jìn)行處理，以使其與HTTP的無狀態(tài)本質(zhì)完全協(xié)調(diào)一致。

好的，我知道每條消息都會自動完成HTTP身份驗證-但是如何？

是的，用戶名和密碼隨每個請求一起發(fā)送。這樣做的常用方法是基本訪問身份驗證和摘要訪問身份驗證。是的，竊聽者可以捕獲用戶的憑據(jù)。因此，將使用傳輸層安全性（TLS）加密所有發(fā)送和接收的數(shù)據(jù)。

擁有一個接受GET請求的REST服務(wù)（例如，/ session）是否會很糟糕，您將在其中傳遞用戶名/密碼作為請求的一部分，如果身份驗證成功，則返回一個會話令牌，這可能然后與后續(xù)請求一起傳遞？從REST的角度來看這是否有意義，還是缺少這一點？

因為它帶有狀態(tài)，所以它不是RESTful的，但是它很常見，因為它為用戶提供了便利。用戶不必每次都登錄。

您在“會話令牌”中描述的內(nèi)容通常稱為登錄cookie。例如，如果您嘗試登錄到Y(jié)ahoo !！帳戶中有一個復(fù)選框，上面寫著“讓我保持登錄狀態(tài)2周”。這實際上是（用您的話）說：“如果我成功登錄，則使我的會話令牌存活2周?！?nbsp;Web瀏覽器將隨您要求的每個HTTP請求一起發(fā)送此類登錄cookie（可能還有其他）。

反對回復(fù) 2020-02-04

森林海

TA貢獻(xiàn)2011條經(jīng)驗獲得超2個贊

REST服務(wù)要求對每個HTTP請求進(jìn)行身份驗證并不罕見。例如，Amazon S3要求每個請求都具有從用戶憑證，要執(zhí)行的確切請求以及當(dāng)前時間派生的簽名。該簽名易于在客戶端進(jìn)行計算，可以由服務(wù)器快速驗證，并且對于攔截該簽名的攻擊者使用有限（因為它基于當(dāng)前時間）。

反對回復(fù) 2020-02-04

達(dá)令說

TA貢獻(xiàn)1821條經(jīng)驗獲得超6個贊

許多人不太清楚REST原理，使用會話令牌并不意味著您總是有狀態(tài)，每個請求發(fā)送用戶名/密碼的原因僅用于身份驗證，并且用于發(fā)送令牌（通過登錄生成）流程）只是為了確定客戶端是否具有請求數(shù)據(jù)的權(quán)限，只有在使用用戶名/密碼或會話令牌來確定要顯示的數(shù)據(jù)時，您才違反REST的要求！取而代之的是，您只能將它們用于衰弱（顯示數(shù)據(jù)或不顯示數(shù)據(jù)）

在您的情況下，我說是，這是RESTy，但請嘗試避免在REST API中使用本機(jī)php會話，并開始生成自己的哈希令牌，這些令牌在確定的時間段內(nèi)到期！

反對回復(fù) 2020-02-04