© 2019 Martin J. Dürst 青山学院大学

ミニテスト

• デスクトップPC (強く推薦) 又はノートPCで https://moo.sw.it.aoyama.ac.jp/ にログイン済み
• ナビゲーションは左に畳み、ブラウザは全画面に拡大
• もう片方のマシーンで電源を切る (ノートPCの場合、鞄に)
• 授業開始まで教科書、資料、筆箱、財布などを鞄に入れ、鞄は床に
• テスト終了後はマウス・キーボードに一切触らないこと

Today's Schedule

• Minitest
• Last week's exercises and homework
• Routing and URI/Path Helpers
• Rails Control Flow
• Callbacks
• Protected and private methods
• Test from two weeks ago
• Today's exercises

Last Lecture's Exercises

Authentication, Authorization, Accounting (AAA)

• Authentication: Is it the right user (login, passwords,...); last week
• Authorization: What is the user allowed to do (roles, permissions); this week
• Accounting: How much does the user have to pay; not this lecture

Caution: Before deploying the examples in this lecture to a real-world application, be sure to carefully check for security problems.

Routing and URI/Path Helpers

• Routing maps paths and methods to controllers and actions
• Example:
  

  controller :sessions do
    post 'login' => :create
  end

  maps the /login path with the POST method to the create action of the sessions controller.
  Alternative:
  post '/login', to 'sessions#create'
  Display in rails routes output:
  

  login POST   /login(.:format)
             sessions#create

• Paths or URLs corresponding to the above are obtained with:
  login_path or login_url
• For more details, see Path and URL Helpers
• These methods are very difficult to search for, because the first part depends on the application.
• To check the result, use View Source in your browser.
• Always use such helpers, do not hard-code URLs or paths in your application.
• Prefer REST-based paths, routes, and actions wherever possible.

Rails Control Flow

(see also diagram in written test)

• Rails is a framework, not just a library.
• This means that Rails itself manages control flow, and calls controllers, models, views, and other code.
• Typical control flow:
  • Request arrives with path and method
  • Path and method are used to map (route) the request to a controller and an action
  • URI parameters and format information are processed
  • Callbacks are called (before_action,...)
  • Controller action itself is called, may call model methods (which may access database)
  • Redirect may be executed (with redirect_to)
  • View is called, starting from the application layout
  • Result is sent back to the browser as a response.
• Exercise: Think about how information is passed from one step to the next.

Callbacks: before_action and Friends

• Many times, some processing is needed before (or after) an action.
• Many times, such processing is the same or similar for many actions.
• Methods doing such processing can be registered as callbacks.
• Registration of callbacks before an action is done with before_action (see examples is controllers generated with scaffold).
• Callbacks can be registered in the application controller, or in a specific controller.
• Callbacks can be limited to certain actions only (with the only: option).
• Callbacks can also be switched off with skip_before_action.
• There are also after_action and around_action callback registration methods for controllers.
• There are similar callbacks for models; see Active Record Callbacks.

Protected and Private Methods

• Methods in Ruby are by default public.
• That means that they can be called from any other object or class.
• Methods that are protected or private cannot be accessed easily from other classes or objects.
• Methods after a protected keyword are protected, after a private keyword, private, after a public keyword, public.
• The meaning of protected and private is not exactly the same as in other programming languages.
• In Rails controllers, all public methods can be used as actions. All other methods are protected or private.

総合復習テストの返却

• Corrected, will be given back today.
• Theoretical maximum is 100 points.
• Achieved maximum is ___ points.
• Average is ___ points.
• Minimum is ___ points.
• Discuss problems/solutions.
• Discuss improvement suggestions.

Exercise Overview

• After each step, use the browser to check that there are no errors in the application.
• If code details are unclear, feel free to ask on Moodle.
• Fix problem with login while logged in (12a).
• Check logins (12b).
• Add user roles (12c).
• Check roles (12d).
• Advanced role check (12e).
• Advanced application layout (12f).

Exercise 12a: Login Fix

• It is currently possible to login as user B while being logged in as user A. This exercise will fix that.
• Before reading on, think about what you would add, and where, to fix this problem.
• You already have all the necessary code. Please think about where this code is.
• Add a check for an existing login to the create action in the session controller.
  (You can use the check in the application layout file as an example.)
• Redirect to the movies index, with a flash alert telling the user to first logout before logging in again.
• Add a check for flash[:alert] to the movies index view, and output any messages that are present.
  (You can use the code in the view for a new session.)
• Submit the sessions controller file as 12a_sessions_controller.rb to Moodle (deadline 17:00).

Exercise 12b: Checking Login

• We need to make sure that some operations are only allowed for users who are logged in.
• In the ApplicationController, create a private method require_login (see example).
• In the ApplicationController, add a before_action with require_login.
• Try to log out. What happens?
• Add a skip_before_action for those controllers/actions that can be viewed without login
  (login itself (new/create), movie/review index/show).
• Check that the pages you made accessible without login are actually accessible without login.
• Submit the application controller as 12b_application_controller.rb and the movies controller as 12b_movies_controller.rb to Moodle (deadline 17:30).

Exercise 12c: Roles for Users

• We need to distinguish between administrators (admin, who are allowed to do anything) and reviewers (reviewer, who can write reviews and edit the reviews they have written).
• Create a migration named AddRoleToUser, adding a column named role with type string. See Exercise 11b for a similar migration. Check the migration.
• Update (migrate) the database.
• Display the role in the user index and show views.
• Add a role field to the user form partial (_form.html.erb).
• Validate inclusion of the role in the set {admin, reviewer} (see example).
• Update the users controller to permit a role parameter.
• Add the correct role to your user(s). Make sure you have at least one admin user and one reviewer user. If necessary, add more users.
• Submit the User model as 12c_user.rb and the form partial as 12c_form.html.erb to Moodle (deadline 18:00).

Exercise 12d: Checking Roles

• In the user model, create a method admin? and a method reviewer? that return true or false depending on the role of the user.
• In the ApplicationController, create a private method require_admin. To get the user, you can use User.find.
• Add a before_action for all those actions that you think only the administrator(s) should be allowed to do
  (destroying anything (except sessions!), editing/updating anything).
• Submit the application controller as 12d_application_controller.rb and the reviews controller as 12d_reviews_controller.rb to Moodle (deadline 18:30).

Exercise 12e: Advanced Exercise (発展問題)

As advanced exercises, you can do exercise 12e only, or exercise 12f only, or both.

• Change the application so that:
  • Reviews can be created directly from the movie index and show views, for the movie in question.
  • When a review is created, the user associated with it is set to the user who is logged in.
  • Users who are creators of a review can edit/update/destroy a review. Administrators can only distroy a review, but not edit/update it.
  • Links (e.g. Show/Edit/Destroy) are only shown if the user is allowed to do this operation.

  In the user model, create a method admin? and a method reviewer? that return true or false depending on the role of the user.

• In the ApplicationController, create a private method require_admin. To get the user, you can use User.find.
• Add a before_action for all those actions that you think only the administrator(s) should be allowed to do
  (destroying anything (except sessions!), updating anything).
• Submit the review controller as 12e_review_controller.rb and the movie index view as 12e_movie_index.html.erb to Moodle (deadline Wednesday 19:00).

Exercise 12f: Advanced Exercise (発展問題)

• Change the application layout so that the yield is included in a div element with a class, and there is some general navigation before it.
• Add styling for the div element and the navigation to the application stylesheet at app/assets/stylesheets/application.css.
• Submit the application layout as 12f_application.html.erb and the application stylesheet as 12f_application.css (deadline Wednesday 19:00).

Homework

• Complete the handout (very legible handwriting) and submit it to the box in front of room O-529 (make sure you choose the correct box!).
• This is a preparatory exercise for the next three weeks.
• Deadline: Friday, July 5, 2019, 19:00.
• Make sure you bring a copy (with copier) of this homework to the next lecture.
• There will be deductions if there are solutions that are too close to each other.