Iteration J3: Limiting Access
We want to prevent people without an administrative login from accessing our site’s admin pages. It turns out that we can do it with very little code using the Rails callback facility.
Rails callbacks allow you to intercept calls to action methods, adding your own processing before they’re invoked, after they return, or both. In our case, we’ll use a before action callback to intercept all calls to the actions in our admin controller. The interceptor can check session[:user_id]. If it’s set and if it corresponds to a user in the database, the application knows an administrator is logged in, and the call can proceed. If it’s not set, the interceptor can issue a redirect, in this case to our login page.
Where should we put this method? It could sit directly in the admin controller, but—for reasons that’ll become apparent shortly—let’s put it instead in ApplicationController, the parent class of all our controllers. This is in the application_controller.rb file in the app/controllers directory. Note too that we chose to restrict access to this method. This prevents it from ever being exposed to end users as an action:
| | class ApplicationController < ActionController::Base |
| » | before_action :authorize |
| | |
| | # ... |
| » | |
| » | protected |
| » | |
| » | def authorize |
| » | unless User.find_by(id: session[:user_id]) |
| » | redirect_to login_url, notice: "Please log in" |
| » | end |
| » | end |
| | end |
The before_action line causes the authorize method to be invoked before every action in our application.
This is going too far. We’ve just limited access to the store itself to administrators. That’s not good.
We could go back and change things so that we mark only those methods that specifically need authorization. Such an approach, called denylisting, is prone to errors of omission. A much better approach is to allowlist—list methods or controllers for which authorization is not required. We do this by inserting a skip_before_action call within the StoreController:
| | class StoreController < ApplicationController |
| » | skip_before_action :authorize |
And we do it again for the SessionsController class:
| | class SessionsController < ApplicationController |
| » | skip_before_action :authorize |
We’re not done yet; we need to allow people to create, update, and delete carts:
| | class CartsController < ApplicationController |
| » | skip_before_action :authorize, only: [:create, :update, :destroy] |
And we allow them to create line items:
| | class LineItemsController < ApplicationController |
| » | skip_before_action :authorize, only: :create |
We also allow them to create orders (which includes access to the new form):
| | class OrdersController < ApplicationController |
| » | skip_before_action :authorize, only: [:new, :create] |
With the authorization logic in place, we can now navigate to http://localhost:3000/products. The callback method intercepts us on the way to the product listing and shows us the login screen instead.
Unfortunately, this change pretty much invalidates most of our functional and system tests, because most operations will now redirect to the login screen instead of doing the function desired. Fortunately, we can address this globally by creating a setup method in the test_helper. While we’re there, we also define some helper methods to login_as and logout a user.
We’ll put those into a module because we need all of these methods to be included in both ActionDispatch::IntegrationTest and ActionDispatch::SystemTestCase. We’ll define a module AuthenticationHelpers and then include that in both classes, like so:
| | module AuthenticationHelpers |
| | def login_as(user) |
| | if respond_to? :visit |
| | visit login_url |
| | fill_in :name, with: user.name |
| | fill_in :password, with: 'secret' |
| | click_on 'Login' |
| | else |
| | post login_url, params: { name: user.name, password: 'secret' } |
| | end |
| | end |
| | |
| | def logout |
| | delete logout_url |
| | end |
| | |
| | def setup |
| | login_as users(:one) |
| | end |
| | end |
| | |
| | class ActionDispatch::IntegrationTest |
| | include AuthenticationHelpers |
| | end |
| | |
| | class ActionDispatch::SystemTestCase |
| | include AuthenticationHelpers |
| | end |
Note that the setup method will call login_as only if session is defined. This prevents the login from being executed in tests that don’t involve a controller.
Also note that the scaffold-generated test in test/system/users_test.rb won’t be passing. That was generated by Rails for us but doesn’t really represent how we implemented login. We’ll leave that as an exercise for you to fix at the end of this chapter.
We show our customer and are rewarded with a big smile and a request: could we add a sidebar and put links to the user and product administration stuff in it? And while we’re there, could we add the ability to list and delete administrative users? You betcha!