每個客戶端都由一個散列標識,並與每個請求一起傳遞給服務器。在這種情況下,處理跟蹤用戶會話的最佳方式是什麼?處理所有rails請求共用的用戶id散列的最佳方式
我對用戶帳戶等使用restful_authentication等大量的請求預計沒有用戶帳戶,而是唯一的哈希。
我對於處理會話方式的理解有限,請牢記這一點。 :)
每個客戶端都由一個散列標識,並與每個請求一起傳遞給服務器。在這種情況下,處理跟蹤用戶會話的最佳方式是什麼?處理所有rails請求共用的用戶id散列的最佳方式
我對用戶帳戶等使用restful_authentication等大量的請求預計沒有用戶帳戶,而是唯一的哈希。
我對於處理會話方式的理解有限,請牢記這一點。 :)
使用這個散列在URL意味着你沒有內置的會話軌。會話的重點是提供請求之間的某種狀態。你已經在提供這種狀態下,看到你路過這兒,哈希,所以在我看來,你可以刪除restful_authentication插件,做這樣的事情,而不是:
class ApplicationController < ActionController::Base
def require_login
if params[:access_key]
@current_user = User.find_by_access_key(params[:access_key]) || restrict_access
else
restrict_access
end
end
def restrict_access
flash[:error] = "You have to log in to access that."
redirect_to root_path
end
end
然後,不要在控制器上before_filter :require_login
哪裏登錄訪問需要。
取決於你想要做什麼,但session
哈希可能會提供你想要的。會話存儲在某個地方(加密的cookie,數據庫或服務器上的文件),並向cookie中的客戶端發送一個唯一的標識符(類似於「散列」)。在隨後的請求中,讀取cookie並將相應的用戶會話數據恢復爲session
散列。
session[:user] = currently_logged_in_user.id
# ... next request ...
session[:user] # returns the currently logged in user's id