Railsチュートリアル第9章
はじめに
Ruby on Railsチュートリアル(第6版)のメモ、演習の解答例を記述した記事です。
解答は個人のものなので、誤りがあればご指摘ください。
開発環境 Ruby: 2.7.2 , Rails: 6.1.4
メモ
Remember me機能
ユーザーのログイン状態を、ブラウザを閉じたあとでも有効にする機能
sessionメソッドを利用したブラウザへのセッション情報は安全が保たれるが、ブラウザを閉じるセッション情報は消えてしまう
そこで、セッションの永続化をcookiesメソッドを利用し、安全性を加味しながら実現する
セッション
一時セッション ：ブラウザを閉じると消えるセッションの事(sessionメソッドを利用)
永続的セッション：ブラウザを閉じても半永久的に消えないセッション(cookiesメソッドを利用)
cookieメソッドでの永続化によるデメリット
cookiesメソッドでは永続的にログインした状態が保たれるが、セッションハイジャック攻撃を受ける可能性がある。
セッションハイジャックの主な手法
- 管理の甘いネットワークを通過するネットワークパケットからパケットスニッファというソフトでcookieを直接取り出す
- データベースから記憶トークンを取り出す
- クロスサイトスクリプティングを使う
- ユーザがログインしているパソコンやスマホを直接操作してアクセス権を奪い取る
cookiesメソッドで状態を保持
sessionのようにハッシュとして扱う
cookiesは1つのvalueとオプションのexpires(有効期限)を持つ
記憶トークンをブラウザに記憶
cookies[:remember_token] = { value: remember_token,
expires: 20.years.from_now.utc }valueに記憶トークンをexpiresに有効期限を渡す。
次のコードも同じ処理をする
cookies.permanent[:remember_token] = remember_token
有効期限を20年とする設定がよく使われるため上記のようなpermanentというメソッドが追加された。
ユーザーIDをブラウザに記憶
signedメソッドで暗号化(署名付きcookie)、permanentメソッドで20年保持
cookies.permanent.signed[:user_id] = user.id
cookiesから暗号化されたユーザーIDを取り出す
cookies.signed[:user_id]
cookies.signed[:user_id]では自動的にcookiesの暗号化を解除し、
続いてbcryptを使ってcookies[:remember_token]がremember_digestと一致するかの確認をする
永続的セッションの削除
cookiesメソッドでブラウザのcookie情報を削除する
cookies.delete(:user_id) #ユーザーIDを削除 cookies.delete(:remember_token) #記憶トークンを削除
assignsメソッド
コントローラーのアクションが実行された後に、コントローラーで定義されたインスタンス変数を参照する。
9.3.1の演習1ではlogin_pathにPOSTリクエストを送りsession_controllerのcreateアクションが実行されたため、このcreateアクションで定義されたインスタンスメソッドを参照している。
raiseメソッド
プログラムの中で意図的に例外を発生させる
herokuメンテナンスモード
メンテナンスモードをオンにすることでページにアクセスできない状態にする。
メンテナンスモードをオン
$ heroku maintenance:on
メンテナンスモードをオフ
$ heroku maintenance:off
演習
9.1.1
演習1
コンソールを開き、データベースにある最初のユーザーを変数userに代入してください。その後、そのuserオブジェクトからrememberメソッドがうまく動くかどうか確認してみましょう。また、remember_tokenとremember_digestの違いも確認してみてください。
remember_digestにはremember_tokenをハッシュ化し値が保存されている。
irb(main):001:0> user = User.first (0.4ms) SELECT sqlite_version(*) User Load (0.1ms) SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ? [["LIMIT", 1]] irb(main):002:0> user.remember User Update (0.3ms) UPDATE "users" SET "updated_at" = ?, "remember_digest" = ? WHERE "users"."id" = ? [["updated_at", "2021-07-11 08:36:08.652655"], ["remember_digest", "$2a$12$1VR./gDUj1Tt8XBN/SA3UO.TyXAKajeuN1868HOW7U1GsULWC9rX2"], ["id", 1]] TRANSACTION (0.6ms) commit transaction => true irb(main):003:0> user.remember_token => "AHgb7ct6KjACo4zSQ2ye2A" irb(main):004:0> user.remember_digest => "$2a$12$1VR./gDUj1Tt8XBN/SA3UO.TyXAKajeuN1868HOW7U1GsULWC9rX2"
9.1.2
演習2
コンソールを開き、リスト 9.6のauthenticated?メソッドがうまく動くかどうか確かめてみましょう。
irb(main):001:0> user = User.first (0.5ms) SELECT sqlite_version(*) User Load (0.1ms) SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ? [["LIMIT", 1]] => #<User id: 1, name: "Rails Tutorial", email: "example@railstutorial.... irb(main):002:0> user.remember User Update (0.3ms) UPDATE "users" SET "updated_at" = ?, "remember_digest" = ? WHERE "users"."id" = ? [["updated_at", "2021-07-11 09:13:30.028775"], ["remember_digest", "$2a$12$YPaIMQRoOJV/a0Qp08e9Lu431JW2QKMu787PgwLVDfid8pHxfiy.a"], ["id", 1]] TRANSACTION (0.6ms) commit transaction => true irb(main):003:0> user.authenticated?(user.remember_token) => true
9.3.1
演習1
リスト 9.25の統合テストでは、仮想のremember_token属性にアクセスできないと説明しましたが、実は、assignsという特殊なテストメソッドを使うとアクセスできるようになります。コントローラで定義したインスタンス変数にテストの内部からアクセスするには、テスト内部でassignsメソッドを使います。このメソッドにはインスタンス変数に対応するシンボルを渡します。例えばcreateアクションで@userというインスタンス変数が定義されていれば、テスト内部ではassigns(:user)と書くことでインスタンス変数にアクセスできます。本チュートリアルのアプリケーションの場合、Sessionsコントローラのcreateアクションでは、userを（インスタンス変数ではない）通常のローカル変数として定義しましたが、これをインスタンス変数に変えてしまえば、cookiesにユーザーの記憶トークンが正しく含まれているかどうかをテストできるようになります。このアイデアに従ってリスト 9.27とリスト 9.28の不足分を埋め（ヒントとして?やFILL_INを目印に置いてあります）、［remember me］チェックボックスのテストを改良してみてください。
createアクション
def create
@user = User.find_by(email: params[:session][:email].downcase)
if @user&.authenticate(params[:session][:password])
log_in @user
params[:session][:remember_me] == '1'? remember(@user) : forget(@user)
redirect_to user_url(@user)
else
flash.now[:danger] = 'Invalid email/password combination'
render 'new'
end
end統合テスト
test "loin with remembering" do
log_in_as(@user, remember_me: '1')
assert_equal cookies[:remember_token], assigns(:user).remember_token
end
おわりに
9章は内容が一気に難しくなった気がします。
処理が複雑になり、どう動いているか意識しながら進めないと混乱しますね、、
Railsチュートリアル第8章
はじめに
Ruby on Railsチュートリアル(第6版)のメモ、演習の解答例を記述した記事です。
解答は個人のものなので、誤りがあればご指摘ください。
開発環境 Ruby: 2.7.2 , Rails: 6.1.4
メモ
認証システム
ログイン済みのユーザーがブラウザを閉じたらログイン状態を破棄する仕組みのこと
認可モデル
ユーザーがログインしているかどうかで使える機能やアクセスできるページを制御すること
セッション
ユーザの状態を保持するためのもの。
Railsでセッションを実装する最も一般的な方法はcookiesを使う方法。
cookiesはブラウザに保存されるテキストデータ。
cookiesに状態を保存する方法は二種類
・sessionメソッド：ブラウザを閉じると自動的にセッションの有効期限が切れる。
・cookiesメソッド：ユーザーがログアウトなどをして意図的にセッションを削除しないとブラウザを閉じてもセッションは長期的にブラウザに保たれる。
sessionメソッドの場合cookiesを盗み出されても盗まれたcookiesでログインされることはない。
Railsのメソッドであるsessionメソッドを利用してユーザの状態を保存する。
session[:user_id] = user.id
セッションを使う際は、Railsの全コントローラの親であるApplicationControllerにセッション用のヘルパーモジュールを読み込ませる必要がある。
class ApplicationController < ActionController::Base include SessionsHelper end
セッションの削除
session.delete(:user_id)
fixture
テスト時にログインできるかどうか検証するためにあらかじめデータを設定しておく必要がある。
このようなテスト用のデータをfixtureで作成できる。
ぼっち演算子
if user && user.authenticate(params[:session][:password])
が次のように書ける
if user&.authenticate(params[:session][:password])
演習
8.2.4
演習1
リスト 8.15の8行目にあるif userから下をすべてコメントアウトすると、ユーザー名とパスワードを入力して認証しなくてもテストが通ってしまうことを確認しましょう（リスト 8.26）。通ってしまう理由は、リスト 8.9では「メールアドレスは正しいがパスワードが誤っている」ケースをテストしていないからです。このテストがないのは重大な手抜かりですので、テストスイートで正しいメールアドレスをUsersのログインテストに追加して、この手抜かりを修正してください（リスト 8.27）。テストが red （失敗）することを確認し、それから先ほどの8行目以降のコメントアウトを元に戻すと green （パス）することを確認してください。
test "login with valid email/invalid password" do
get login_path
assert_template 'sessions/new'
post login_path, params: { session: { email: @user.email, password: "invalid"}}
assert_template 'sessions/new'
assert flash.any?
get root_path
assert flash.empty?
endif user から下をコメントアウトしてテスト(RED)
yuy@yu sample_app % rails test
Running via Spring preloader in process 53231
Started with run options --seed 3080
FAIL["test_login_with_valid_email/invalid_password", #<Minitest::Reporters::Suite:0x0000000136ce2b38 @name="UsersLoginTest">, 0.40365799999563023]
test_login_with_valid_email/invalid_password#UsersLoginTest (0.40s)
expecting <"sessions/new"> but rendering with <[]>
test/integration/users_login_test.rb:35:in `block in <class:UsersLoginTest>'
24/24: [=============================] 100% Time: 00:00:00, Time: 00:00:00
Finished in 0.63630s
24 tests, 62 assertions, 1 failures, 0 errors, 0 skipsコメントアウトを消してテスト(GREEN)
Running via Spring preloader in process 53284 Started with run options --seed 17884 24/24: [=============================] 100% Time: 00:00:00, Time: 00:00:00 Finished in 0.72054s 24 tests, 64 assertions, 0 failures, 0 errors, 0 skips
おわりに
演習の解答を書くと言っておいて全然記述しいてなくてすみませんm(__)m
コンソールで確認する演習やブラウザで確認する演習は手間がかかるので、、
ぼっち演算子の名前が面白くてすこし調べてみたところ&.が一人でしゃがんでるように見えるからだとか、、
確かに見えなくもないですね笑
折り返し地点にきました！
引き続き頑張ります！！
Railsチュートリアル第7章
はじめに
Ruby on Railsチュートリアル(第6版)のメモ、演習の解答例を記述した記事です。
解答は個人のものなので、誤りがあればご指摘ください。
開発環境 Ruby: 2.7.2 , Rails: 6.1.4
メモ
debugger
byebug gemのdebuggerメソッドをコード内に埋め込むことで埋め込んだ箇所の状況を調べることができる。
調べたあとはコード内からdebuggerを取り除く必要がある。
ヘルパー
form_with
form_withヘルパーはAcrive Recordのオブジェクトを取り込み、取り込んだオブジェクトの属性を使ってフォームを構築する。
参考：form_with | Railsドキュメント
content_tag
HTMLとERBが混ざっているときに置き換えるとコードが簡潔になる。
7.4.4の演習2を参照
参考：
content_tag | Railsドキュメント
ストロングパラメータ
マスアサインメントの脆弱性を対策するためのもの。
必須のパラメータと許可されたパラメータを指定して受け取ることができる。
こうすることで意図的にパラメータを書き換えられることを防ぐ
params.require(:user).permit(:name, :email, :password, :password_confirmation)
必須の属性を:userとし、名前、メールアドレス、パスワード、パスワードの確認を許可している。それ以外のパラメータはエラーとして弾くようになっている。
演習
7.3.4
演習1
リスト 7.20で実装したエラーメッセージに対するテストを書いてみてください。どのくらい細かくテストするかはお任せします。リスト 7.25にテンプレートを用意しておいたので、参考にしてください。
POSTリクエストを送信した際のエラーメッセージを追加
test "invalid signup information" do
get signup_path
assert_no_difference "User.count" do
post users_path, params: { user: { name: "", email: "user@invalid", password: "foo", password_confirmation: "bar" } }
end
assert_template 'users/new'
assert_select 'div#error_explanation'
assert_select 'div.field_with_errors'
assert_select 'li', "Name can't be blank"
assert_select 'li', "Email is invalid"
assert_select 'li', "Password confirmation doesn't match Password"
assert_select 'li', "Password is too short (minimum is 6 characters)"
end
7.4.4
演習1
7.4.2で実装したflashに対するテストを書いてみてください。どのくらい細かくテストするかはお任せします。リスト 7.32に最小限のテンプレートを用意しておいたので、参考にしてください（FILL_INの部分を適切なコードに置き換えると完成します）。ちなみに、テキストに対するテストは壊れやすいです。文量の少ないflashのキーであっても、それは同じです。筆者の場合、flashが空でないかをテストするだけの場合が多いです。
test "valid signup information" do
get signup_path
assert_difference "User.count", 1 do
post users_path, params: { user: { name: "Example User", email: "user@example.com", password: "password", password_confirmation: "password" }}
end
follow_redirect!
assert_template 'users/show'
assert_not flash.empty?
end
演習2
本文中でも指摘しましたが、flash用のHTML（リスト 7.29）は読みにくいです。より読みやすくしたリスト 7.33のコードに変更してみましょう。変更が終わったらテストスイートを実行し、正常に動作することを確認してください。なお、このコードでは、Railsのcontent_tagというヘルパーを使っています。
<div class="alert alert-<%= message_type %>"><%= message %></div>
HTMLとERBが混在しているコードをcontent_tagで置き換えると
<%= content_tag(:div, message, class: "alert alert-#{message_type}")%>
演習3
リスト 7.26のリダイレクトの行をコメントアウトすると、テストが失敗することを確認してみましょう。
# redirect_to user_url @user
テストの結果
yuy@yu sample_app % rails test
Running via Spring preloader in process 45196
Started with run options --seed 2921
ERROR["test_valid_signup_information", #<Minitest::Reporters::Suite:0x0000000114b9c728 @name="UsersSignupTest">, 0.32726700004423037]
test_valid_signup_information#UsersSignupTest (0.33s)
RuntimeError: RuntimeError: not a redirect! 204 No Content
test/integration/users_signup_test.rb:24:in `block in <class:UsersSignupTest>'
20/20: [=============================] 100% Time: 00:00:00, Time: 00:00:00
Finished in 0.42140s
20 tests, 47 assertions, 0 failures, 1 errors, 0 skips
演習4
リスト 7.26で、@user.saveの部分をfalseに置き換えたとしましょう（バグを埋め込んでしまったと仮定してください）。このとき、assert_differenceのテストではどのようにしてこのバグを検知するでしょうか? テストコードを追って考えてみてください
def create
@user = User.new(user_params)
if false
flash[:success] = "Welcome to the Sample App!"
redirect_to user_url @user
else
render 'new'
end
endPOSTリクエストを送信したあとのデータベースの変化についてエラーが出ている。
yuy@yu sample_app % rails test
Running via Spring preloader in process 46971
Started with run options --seed 47383
FAIL["test_invalid_signup_information", #<Minitest::Reporters::Suite:0x000000011fc5b988 @name="UsersSignupTest">, 0.45664799999212846]
test_invalid_signup_information#UsersSignupTest (0.46s)
Expected at least 1 element matching "div#error_explanation", found 0..
Expected 0 to be >= 1.
test/integration/users_signup_test.rb:11:in `block in <class:UsersSignupTest>'
FAIL["test_valid_signup_information", #<Minitest::Reporters::Suite:0x000000011fc50cb8 @name="UsersSignupTest">, 0.4575549999717623]
test_valid_signup_information#UsersSignupTest (0.46s)
"User.count" didn't change by 1.
Expected: 1
Actual: 0
test/integration/users_signup_test.rb:21:in `block in <class:UsersSignupTest>'
20/20: [=============================] 100% Time: 00:00:00, Time: 00:00:00
Finished in 0.51240s
20 tests, 42 assertions, 2 failures, 0 errors, 0 skips
おわりに
本章の終わりに本番環境の設定をしましたが、そこではセキュリティ面とユーザーが利用しやすい環境を作ることが大切だということが窺えました。
引き続き次の章もがんばります！！
Railsチュートリアル第6章
はじめに
Ruby on Railsチュートリアル(第6版)のメモ、演習の解答例を記述した記事です。
解答は個人のものなので、誤りがあればご指摘ください。
開発環境 Ruby: 2.7.2 , Rails: 6.1.4
メモ
Active Record
データベースとやり取りをするデフォルトのライブラリ
このライブラリのおかげで直接SQL文を書かずにRailsのメソッドでデータベースを操作できる。
(O/Rマッピング)
Active Recordはデータオブジェクトの作成、保存、検索のためのメソッドを持っている。
スキーマ
データベースの構造を追跡するために使われる。
db/schema.rb
モデル
モデルの生成
$ rails generate model モデル名(単数形)
作成したモデルはApplicationRecordを継承している。
ApplicationRecordはActive Recordを継承している。
つまり生成したモデルはActive Recordのメソッドが使える
CRUD
データベースの操作を表す「Create」、「Read」、「Update」、「Delete」の頭文字。
Active RecordはCRUDのメソッドを生成するのでActive Recordを継承したモデルでもこれらのメソッドを利用できる。
例：user.new, user.find, user.update, user.destroy ...
update_attributeメソッドは検証を回避して更新することができる
参考：Active Record の基礎 - Railsガイド
検証
ActiveRecordでは検証(Validation)という機能でモデルの属性に制約を課すことができる。
よく使われるバリデーションヘルパー
・存在性 (presence)
・長さ (length)
・フォーマット (format)
・一意性 (uniqueness)
・確認 (confirmation)
参考：Active Record バリデーション - Railsガイド
有効性の検証
バリデーション機能が正常に動いているかはテストで確かめる
- 有効なモデルのオブジェクトを作成
- 作成したオブジェクトのうちの1つを有効でない属性に意図的に変更する
- バリデーションで失敗するかテストする
- テストが成功するようにモデルにバリデーションを設定する
- テストが成功するか確認する
一意性の検証
モデルの一意性を検証するときにメモリ上だけでなく実際にレコードをデータベースに登録して検証する必要がある。
テスト上で登録したレコードは"db/test.sqlite3"のテスト用のデータベースに保存される。
test "email addresses should be unique" do
duplicate_user = @user.dup #dupでオブジェクトを複製
@user.save #db/test.sqlite3のデータベースに登録
assert_not duplicate_user.valid?
end
インデックス
通常テーブルの中から特定のカラムを検索するとき、テーブルの上から下まで探したいカラムを闇雲に探す。
このままだと、数千人、数万人が登録されたデータベースから一人を探すのは時間がかかる、
そこでインデックスを使うと早く検索できるらしい、、
indexを追加する
$ rails generate migration add_index_to_テーブル名_カラム名
生成されたmigrationファイルは以下のようになる。
class AddIndexToテーブル名 < ActiveRecord::Migration
def change
add_index :テーブル名, カラム名[, unique: true ]
end
endRailsチュートリアルでは"unique: true"を追加して一意性を強制している。
参考：データベースにindexを張る方法 - Qiita
コールバック
オブジェクトの保存、更新、削除の際に処理を実行させる
コールバックを使う際は慎重に、、、
苦しめられてやっと理解できたRailsコールバックの使い方 - KitchHike Tech Blog
reloadメソッド
現在のデータベースと同じ値に更新する。
user = User.new( name: "user", email: "user@example.com" ) => #<User id: nil, name: "user", email: "user@example.com", created_at: nil, updated_at: nil, password_digest: nil> user.save => true user.name = "hogehoge" => "hogehoge" user.reload.name => "user"
セキュアなパスワード
パスワード、パスワードの確認をユーザーに入力してもらい、そのデータをハッシュ化してデータベースに保存することで安全性を保つ。
ハッシュ化されたパスワードを保存するには
- モデルにpassword_digesカラムを追加する
- ハッシュ関数を導入する(bcrypt)
- モデルでhas_secure_passwordメソッドを呼び出す
has_secure_passwordを呼び出したモデルは以下の機能が使えるようになる
・ハッシュ化したパスワードをpassword_digestに保存できるようになる
・ペアの仮想的な属性であるpasswordとpassword_confirmationが使えるようになる
存在性とpasswordとpassword_confirmationが一致するかどうかのバリデーションも追加される
・authenticateメソッドが使えるようになる
おわりに
6章ではUserテーブルを作りバリデーションの設定、セキュアなパスワードの追加をしました。
has_secure_passwordの力恐るべしです。
Railsチュートリアル第5章
はじめに
Ruby on Railsチュートリアル(第6版)のメモ、演習の解答例を記述した記事です。
解答は個人のものなので、誤りがあればご指摘ください。
開発環境 Ruby: 2.7.2 , Rails: 6.1.4
メモ
ヘルパー
5章で新出のヘルパー
image_tag
イメージタグを生成する。
app/assets/images配下に画像を置いた場合の例
image_tag("rails.svg", alt: "Rails logo", width: "200px")
アセットパイプライン
個別のアセット(画像、CSS、JavaScript)を最小化、圧縮、連結する一連の機能のこと。
サーバーへのリクエストを減らしたりファイルの使用頻度を減らすというメリットがある。
マニフェストファイル
アセットをどのように１つのファイルにまとめるかをRailsに指示するためのファイルのこと。
実際にアセットをまとめる処理を行うのはSprocketsというgem
※Rails６からはwebpackが採用されている
<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %> <%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>
デフォルトで作成されるファイルのhead内には上記の記述がある
つまりデフォルトでは
assets/stylesheets/application.css
assets/javascripts/aapplication.js
をマニフェストファイルとして指定している
名前付きルート
get '/help', to: 'static_pages#help'
上記のようにルートを設定するとhelp_pathやhelp_urlのような名前付きルートを使えるようになる。
help_pathとhelp_urlでは返す値が違う。
help_path -> '/help' help_url -> 'https://www.example.com/help'
Railsチュートリアルでは基本的に〇〇_pathを使い、リダイレクトするときのみ〇〇_urlを使う。HTTPの標準としてはリダイレクトするときは完全なURLが要求されるから_urlを使う。
統合テスト
複数のアプリケーションの機能が連動しているか、そして連動している処理が正常に動くかを確かめるテストのこと。
$ rails generate integration_test 統合テスト名
演習メモ
5.3.4の演習でApplicationヘルパーをテストで使えるようにインクルードしている。
おわりに
5章ではメインページのレイアウトを作成して、リンクを追加することで別のページと行き来することができるようになりました。
アセットパイプラインが雰囲気しかわかっていないからちゃんと理解しないと、、、
今度テストについてまとめたいです！
Railsチュートリアル第4章
はじめに
Ruby on Railsチュートリアル(第6版)のメモ、演習の解答例を記述した記事です。
解答は個人のものなので、誤りがあればご指摘ください。
開発環境 Ruby: 2.7.2 , Rails: 6.1.4
メモ
ヘルパー
ヘルパーはビューで使うための関数のこと。
これによりビューを効率よくシンプルに書くことができる。
HTML生成を行うものやURLを生成するメソッドなどがある。
カスタムヘルパー
自分で新しく作成したヘルパーのこと。
カスタムヘルパーは"app/helpers"配下のモジュールに記述していく。
"application_helper.rb"にはアプリケーション全体で利用するヘルパーを定義する。
参考に、"user_helper.rb"ではuser配下で利用するヘルパーを定義する。
また、Railsではヘルパーモジュールを自動的に読み込んでくれるのでincludeする必要がない。
Railsコンソール
次のコマンドで起動
$ rails console Loading development environment
コンソールにはdevelpment、test、productionの3種類がありデフォルトではdevelopmentで起動される。
括弧の省略
関数の最後の引数にハッシュを渡すとき波括弧を省略することができる。
stylesheet_link_tag 'application', media: 'all',
'data-turbolinks-track': 'reload'省略せずに書くと
stylesheet_link_tag( 'application', { media: 'all',
'data-turbolinks-track': 'reload' } )第1引数：スタイルシートへのパス
第2引数：" media: 'all' " -- メディアタイプ
" 'data-turbolinks-track': 'reload' " --turbolinks機能をオン
Railsチュートリアル第３章
はじめに
Ruby on Railsチュートリアル(第6版)のメモ、演習の解答例を記述した記事です。
解答は個人のものなので、誤りがあればご指摘ください。
開発環境 Ruby: 2.7.2 , Rails: 6.1.4
メモ
開発中の失敗をもとに戻す方法
コントローラの自動生成と取り消し
取り消す場合はコントローラとそれに対応するアクションを記述
$ rails generate controller コントローラ名(複数形) アクション名 $ rails destroy controller コントローラ名(複数形) アクション名
テスト駆動開発(TDD)
テスト手法のひとつ。
プログラムを実装する前にテストコードを書き、そのテストコードに適合するようにプログラムを実装、リファクタリングしていく手法。
$ rails test #Railsのテストスクリプト
コントローラやモデルの単体テストを先に行い、続いて統合テストを行っていく。
RED? GREEN?
多くのテストツールでは、テストの失敗をRED、成功をGREENと表現する。
テスト駆動開発のサイクルを「RED・GREEN・REFACTOR」と呼ぶこともある。
application.html.erbのhead部
<%= csrf_meta_tags %> <%= csp_meta_tag %>
csrf_meta_tagsタグ ：クロスサイトリクエストフォージェリー攻撃を緩和
csp_meta_tagタグ ：クロスサイトスクリプティング攻撃を緩和
