9.2 權限系統 · Ruby on Rails 教程

# 9.2 權限系統在 Web 應用中，認證系統的功能是識別網站的用戶，權限系統是控制用戶可以做什么操作。[第 8 章](chapter8.html#log-in-log-out)實現的認證機制有一個很好的作用，可以實現權限系統。雖然 [9.1 節](#updating-users)已經完成了 `edit` 和 `update` 動作，但是卻有一個荒唐的安全隱患：任何人（甚至是未登錄的用戶）都可以訪問這兩個動作，而且登錄后的用戶可以更新所有其他用戶的資料。本節我們要實現一種安全機制，限制用戶必須先登錄才能更新自己的資料，而且不能更新別人的資料。 [9.2.1 節](#requiring-logged-in-users)要處理未登錄用戶試圖訪問有權訪問的保護頁面。因為在使用應用的過程中經常會發生這種情況，所以我們要把這些用戶轉向登錄頁面，而且會顯示一個幫助消息，構思圖如[圖 9.6](#fig-login-page-protected-mockup) 所示。另一種情況是，用戶嘗試訪問沒有權限查看的頁面（例如已登錄的用戶試圖訪問其他用戶的編輯頁面），此時要把用戶重定向到根地址（[9.2.2 節](#requiring-the-right-user)）。 ![login page protected mockup](https://box.kancloud.cn/2016-05-11_5733305ceb780.png)圖 9.6：訪問受保護頁面時看到的頁面構思圖 ## 9.2.1 必須先登錄為了實現[圖 9.6](#fig-login-page-protected-mockup) 中的轉向功能，我們要在用戶控制器中使用“事前過濾器”。事前過濾器通過 `before_action` 方法設定，指定在某個動作運行前調用一個方法。[[3](#fn-3)]為了實現要求用戶先登錄的限制，我們要定義一個名為 `logged_in_user` 的方法，然后使用 `before_action :logged_in_user` 調用這個方法，如[代碼清單 9.12](#listing-authorize-before-filter) 所示。 ##### 代碼清單 9.12：添加 `logged_in_user` 事前過濾器 RED app/controllers/users_controller.rb ``` class UsersController < ApplicationController before_action :logged_in_user, only: [:edit, :update] . . . private def user_params params.require(:user).permit(:name, :email, :password, :password_confirmation) end # 事前過濾器 # 確保用戶已登錄 def logged_in_user unless logged_in? flash[:danger] = "Please log in." redirect_to login_url end end end ``` 默認情況下，事前過濾器會應用于控制器中的所有動作，所以在上述代碼中我們傳入了 `:only` 參數，指定只應用在 `edit` 和 `update` 動作上。退出后再訪問用戶編輯頁面 [/users/1/edit](http://localhost:3000/users/1/edit)，可以看到這個事前過濾器的效果，如[圖 9.7](#fig-protected-log-in) 所示。 ![protected log in 3rd edition](https://box.kancloud.cn/2016-05-11_5733305d1c57b.png)圖 9.7：嘗試訪問受保護頁面后顯示的登錄表單如[代碼清單 9.12](#listing-authorize-before-filter) 的標題所示，現在測試組件無法通過： ##### 代碼清單 9.13：**RED** ``` $ bundle exec rake test ``` 這是因為現在 `edit` 和 `update` 動作都需要用戶先登錄，而在相應的測試中沒有已登錄的用戶。所以，在測試訪問 `edit` 和 `update` 動作之前，要先登入用戶。這個操作可以通過 [8.4.6 節](chapter8.html#remember-tests)定義的 `log_in_as` 輔助方法（[代碼清單 8.50](chapter8.html#listing-test-helper-log-in)）輕易實現，如[代碼清單 9.14](#listing-edit-tests-logged-in) 所示。 ##### 代碼清單 9.14：登入測試用戶 GREEN test/integration/users_edit_test.rb ``` require 'test_helper' class UsersEditTest < ActionDispatch::IntegrationTest def setup @user = users(:michael) end test "unsuccessful edit" do log_in_as(@user) get edit_user_path(@user) . . . end test "successful edit" do log_in_as(@user) get edit_user_path(@user) . . . end end ``` （可以把登入測試用戶的代碼放在 `setup` 方法中，去除一些重復。但是，在 [9.2.3 節](#friendly-forwarding)我們要修改其中一個測試，在登錄前訪問編輯頁面，如果把登錄操作放在 `setup` 方法中就不能先訪問其他頁面了。）現在，測試組件應該可以通過了： ##### 代碼清單 9.15：**GREEN** ``` $ bundle exec rake test ``` 測試組件雖然通過了，但是對事前過濾器的測試還沒完，因為即便把安全防護去掉，測試也能通過。你可以把事前過濾器注釋掉確認一下，如[代碼清單 9.16](#listing-commented-out-before-filter) 所示。這可不妙。在測試組件能捕獲的所有回歸中，重大安全漏洞或許是最重要的。按照[代碼清單 9.16](#listing-commented-out-before-filter) 的方式修改后，測試絕對不能通過。下面我們編寫測試捕獲這個問題。 ##### 代碼清單 9.16：注釋掉事前過濾器，測試安全防護措施 GREEN app/controllers/users_controller.rb ``` class UsersController < ApplicationController # before_action :logged_in_user, only: [:edit, :update] . . . end ``` 事前過濾器應用在指定的各個動作上，因此我們要在用戶控制器的測試中編寫相應的測試。我們計劃使用正確的請求方法訪問 `edit` 和 `update` 動作，然后確認把用戶重定向到了登錄地址。由[表 7.1](chapter7.html#table-restful-users) 得知，正確的請求方法分別是 `GET` 和 `PATCH`，所以在測試中要使用 `get` 和 `patch`，如[代碼清單 9.17](#listing-edit-update-redirect-tests) 所示。 ##### 代碼清單 9.17：測試 `edit` 和 `update` 動作是受保護的 RED test/controllers/users_controller_test.rb ``` require 'test_helper' class UsersControllerTest < ActionController::TestCase def setup @user = users(:michael) end test "should get new" do get :new assert_response :success end test "should redirect edit when not logged in" do get :edit, id: @user assert_redirected_to login_url end test "should redirect update when not logged in" do patch :update, id: @user, user: { name: @user.name, email: @user.email } assert_redirected_to login_url end end ``` 注意 `get` 和 `patch` 的參數： ``` get :edit, id: @user ``` 和 ``` patch :update, id: @user, user: { name: @user.name, email: @user.email } ``` 這里使用了一個 Rails 約定：指定 `id: @user` 時，Rails 會自動使用 `@user.id`。在 `patch` 方法中還要指定一個 `user` 哈希，這樣路由才能正常運行。（如果查看[第 2 章](chapter2.html#a-toy-app)為玩具應用生成的用戶控制器測試，會看到上述代碼。）測試組件現在無法通過，和我們預期的一樣。為了讓測試通過，我們只需把事前過濾器的注釋去掉，如[代碼清單 9.18](#listing-uncommented-before-filter) 所示。 ##### 代碼清單 9.18：去掉事前過濾器的注釋 GREEN app/controllers/users_controller.rb ``` class UsersController < ApplicationController before_action :logged_in_user, only: [:edit, :update] . . . end ``` 這樣修改之后，測試組件應該可以通過了： ##### 代碼清單 9.19：**GREEN** ``` $ bundle exec rake test ``` 如果不小心讓未授權的用戶能訪問 `edit` 動作，現在測試組件能立即捕獲。 ## 9.2.2 用戶只能編輯自己的資料當然，要求用戶必須先登錄還不夠，用戶必須只能編輯自己的資料。由 [9.2.1 節](#requiring-logged-in-users)得知，測試組件很容易漏掉基本的安全缺陷，所以我們要使用測試驅動開發技術確保寫出的代碼能正確實現安全機制。為此，我們要在用戶控制器的測試中添加一些測試，完善[代碼清單 9.17](#listing-edit-update-redirect-tests)。為了確保用戶不能編輯其他用戶的信息，我們需要登入第二個用戶。所以，在用戶固件文件中要再添加一個用戶，如[代碼清單 9.20](#listing-fixture-second-user) 所示。 ##### 代碼清單 9.20：在固件文件中添加第二個用戶 test/fixtures/users.yml ``` michael: name: Michael Example email: michael@example.com password_digest: <%= User.digest('password') %> archer: name: Sterling Archer email: duchess@example.gov password_digest: <%= User.digest('password') %> ``` 使用[代碼清單 8.50](chapter8.html#listing-test-helper-log-in) 中定義的 `log_in_as` 方法，我們可以使用[代碼清單 9.21](#listing-edit-update-wrong-user-tests) 中的代碼測試 `edit` 和 `update` 動作。注意，這里沒有重定向到登錄地址，而是根地址，因為試圖編輯其他用戶資料的用戶已經登錄了。 ##### 代碼清單 9.21：嘗試編輯其他用戶資料的測試 RED test/controllers/users_controller_test.rb ``` require 'test_helper' class UsersControllerTest < ActionController::TestCase def setup @user = users(:michael) @other_user = users(:archer) end test "should get new" do get :new assert_response :success end test "should redirect edit when not logged in" do get :edit, id: @user assert_redirected_to login_url end test "should redirect update when not logged in" do patch :update, id: @user, user: { name: @user.name, email: @user.email } assert_redirected_to login_url end test "should redirect edit when logged in as wrong user" do log_in_as(@other_user) get :edit, id: @user assert_redirected_to root_url end test "should redirect update when logged in as wrong user" do log_in_as(@other_user) patch :update, id: @user, user: { name: @user.name, email: @user.email } assert_redirected_to root_url end end ``` 為了重定向試圖編輯其他用戶資料的用戶，我們要定義一個名為 `correct_user` 的方法，然后設定一個事前過濾器調用這個方法，如[代碼清單 9.22](#listing-correct-user-before-filter) 所示。注意，`correct_user` 中定義了 `@user` 變量，所以可以把 `edit` 和 `update` 動作中的 `@user` 賦值語句刪掉。 ##### 代碼清單 9.22：保護 `edit` 和 `update` 動作的 `correct_user` 事前過濾器 GREEN app/controllers/users_controller.rb ``` class UsersController < ApplicationController before_action :logged_in_user, only: [:edit, :update] before_action :correct_user, only: [:edit, :update] . . . def edit end def update if @user.update_attributes(user_params) flash[:success] = "Profile updated" redirect_to @user else render 'edit' end end . . . private def user_params params.require(:user).permit(:name, :email, :password, :password_confirmation) end # 事前過濾器 # 確保用戶已登錄 def logged_in_user unless logged_in? flash[:danger] = "Please log in." redirect_to login_url end end # 確保是正確的用戶 def correct_user @user = User.find(params[:id]) redirect_to(root_url) unless @user == current_user end end ``` 現在，測試組件應該可以通過： ##### 代碼清單 9.23：**GREEN** ``` $ bundle exec rake test ``` 最后，我們還要重構一下。我們要遵守一般約定，定義 `current_user?` 方法，返回布爾值，然后在 `correct_user` 中調用。我們要在會話輔助方法模塊中定義這個方法，如[代碼清單 9.24](#listing-current-user-p) 所示。然后我們就可以把 ``` unless @user == current_user ``` 改成意義稍微明確一點兒的 ``` unless current_user?(@user) ``` ##### 代碼清單 9.24：`current_user?` 方法 app/helpers/sessions_helper.rb ``` module SessionsHelper # 登入指定的用戶 def log_in(user) session[:user_id] = user.id end # 在持久會話中記住用戶 def remember(user) user.remember cookies.permanent.signed[:user_id] = user.id cookies.permanent[:remember_token] = user.remember_token end # 如果指定用戶是當前用戶，返回 true def current_user?(user) user == current_user end . . . end ``` 把直接比較的代碼換成返回布爾值的方法后，得到的代碼如[代碼清單 9.25](#listing-correct-user-before-filter-boolean) 所示。 ##### 代碼清單 9.25：`correct_user` 的最終版本 GREEN app/controllers/users_controller.rb ``` class UsersController < ApplicationController before_action :logged_in_user, only: [:edit, :update] before_action :correct_user, only: [:edit, :update] . . . def edit end def update if @user.update_attributes(user_params) flash[:success] = "Profile updated" redirect_to @user else render 'edit' end end . . . private def user_params params.require(:user).permit(:name, :email, :password, :password_confirmation) end # 事前過濾器 # 確保用戶已登錄 def logged_in_user unless logged_in? flash[:danger] = "Please log in." redirect_to login_url end end # 確保是正確的用戶 def correct_user @user = User.find(params[:id]) redirect_to(root_url) unless current_user?(@user) end end ``` ## 9.2.3 友好的轉向網站的權限系統完成了，但是還有一個小瑕疵：不管用戶嘗試訪問的是哪個受保護的頁面，登錄后都會重定向到資料頁面。也就是說，如果未登錄的用戶訪問了編輯資料頁面，網站要求先登錄，登錄后會重定向到 /users/1，而不是 /users/1/edit。如果登錄后能重定向到用戶之前想訪問的頁面就更好了。實現這種需求所需的應用代碼有點兒復雜，不過測試很簡單，我們只需把[代碼清單 9.14](#listing-edit-tests-logged-in) 中登錄和訪問編輯頁面兩個操作調換順序即可。如[代碼清單 9.26](#listing-friendly-forwarding-test) 所示，最終寫出的測試先訪問編輯頁面，然后登錄，最后確認把用戶重定向到了編輯頁面，而不是資料頁面。 ##### 代碼清單 9.26：測試友好的轉向 RED test/integration/users_edit_test.rb ``` require 'test_helper' class UsersEditTest < ActionDispatch::IntegrationTest def setup @user = users(:michael) end . . . test "successful edit with friendly forwarding" do get edit_user_path(@user) log_in_as(@user) assert_redirected_to edit_user_path(@user) name = "Foo Bar" email = "foo@bar.com" patch user_path(@user), user: { name: name, email: email, password: "", password_confirmation: "" } assert_not flash.empty? assert_redirected_to @user @user.reload assert_equal @user.name, name assert_equal @user.email, email end end ``` 有了一個失敗測試，現在可以實現友好的轉向了。[[4](#fn-4)]要轉向用戶真正想訪問的頁面，我們要在某個地方存儲這個頁面的地址，登錄后再轉向這個頁面。我們要通過兩個方法來實現這個過程，`store_location` 和 `redirect_back_or`，都在會話輔助方法模塊中定義，如[代碼清單 9.27](#listing-friendly-forwarding-code) 所示。 ##### 代碼清單 9.27：實現友好的轉向 app/helpers/sessions_helper.rb ``` module SessionsHelper . . . # 重定向到存儲的地址，或者默認地址 def redirect_back_or(default) redirect_to(session[:forwarding_url] || default) session.delete(:forwarding_url) end # 存儲以后需要獲取的地址 def store_location session[:forwarding_url] = request.url if request.get? end end ``` 我們使用 `session` 存儲轉向地址，和 [8.2.1 節](chapter8.html#the-log-in-method)登入用戶的方式類似。[代碼清單 9.27](#listing-friendly-forwarding-code) 還用到了 `request` 對象，獲取請求頁面的地址（`request.url`）。在 `store_location` 方法中，把請求的地址存儲在 `session[:forwarding_url]` 中，而且只在 `GET` 請求中才存儲。這么做，當未登錄的用戶提交表單時，不會存儲轉向地址（這種情況雖然罕見，但在提交表單前，如果用戶手動刪除了會話，還是會發生的）。如果存儲了，那么本來期望接收 `POST`、`PATCH` 或 `DELETE` 請求的動作實際收到的是 `GET` 請求，會導致錯誤。加上 `if request.get?` 能避免發生這種錯誤。[[5](#fn-5)] 要使用 `store_location`，我們要把它加入 `logged_in_user` 事前過濾器中，如[代碼清單 9.28](#listing-add-store-location) 所示。 ##### 代碼清單 9.28：把 `store_location` 添加到 `logged_in_user` 事前過濾器中 app/controllers/users_controller.rb ``` class UsersController < ApplicationController before_action :logged_in_user, only: [:edit, :update] before_action :correct_user, only: [:edit, :update] . . . def edit end . . . private def user_params params.require(:user).permit(:name, :email, :password, :password_confirmation) end # 事前過濾器 # 確保用戶已登錄 def logged_in_user unless logged_in? store_location flash[:danger] = "Please log in." redirect_to login_url end end # 確保是正確的用戶 def correct_user @user = User.find(params[:id]) redirect_to(root_url) unless current_user?(@user) end end ``` 實現轉向操作，要在會話控制器的 `create` 動作中調用 `redirect_back_or` 方法，如果存儲了之前請求的地址，就重定向這個地址，否則重定向到一個默認的地址，如[代碼清單 9.29](#listing-friendly-session-create) 所示。`redirect_back_or` 方法中使用了 `||` 操作符： ``` session[:forwarding_url] || default ``` 如果 `session[:forwarding_url]` 的值不為 `nil`，就返回其中存儲的值，否則返回默認的地址。注意，[代碼清單 9.27](#listing-friendly-forwarding-code) 處理得很謹慎，刪除了轉向地址。如果不刪除，后續登錄會不斷重定向到受保護的頁面，用戶只能關閉瀏覽器。（針對這個表現的測試留作[練習](#updating-showing-and-deleting-users-exercises)。）還要注意，即便先重定向了，還是會刪除會話中的轉向地址，因為除非明確使用了 `return` 或者到了方法的末尾，否則重定向之后的代碼仍然會執行。 ##### 代碼清單 9.29：加入友好轉向后的 `create` 動作 app/controllers/sessions_controller.rb ``` class SessionsController < ApplicationController . . . def create user = User.find_by(email: params[:session][:email].downcase) if user && user.authenticate(params[:session][:password]) log_in user params[:session][:remember_me] == '1' ? remember(user) : forget(user) redirect_back_or user else flash.now[:danger] = 'Invalid email/password combination' render 'new' end end . . . end ``` 現在，[代碼清單 9.26](#listing-friendly-forwarding-test) 中針對友好轉向的集成測試應該可以通過了。而且，基本的用戶認證和頁面保護機制也完成了。和之前一樣，在繼續之前，最好運行測試組件，確認可以通過： ##### 代碼清單 9.30：**GREEN** ``` $ bundle exec rake test ```