14.3 ステータスフィード ステータスフィードを実装する！ →フォローされているユーザーのマイクロポストとログイン中のユーザーのマイクロポストを合わせて表示する 見本はこちら→RoRT本文参照 14.3.1 動機と計画 現在のユーザーによってフォローされているユーザーに対応するユーザーidを持つマイクロポストを取り出し、同時に現在のユーザー自身のマイクロポストも一緒に取り出すことです。 図 テストの方が明確な雰囲気なのでテストから書いていく（テスト駆動開発！） フィードのテスト フォローしているユーザーのマイクロポストがフィードに含まれている 自分自身のマイクロポストもフィードに含まれている フォローしていないユーザーのマイクロポストがフィードに含まれていない 上記3つの条件を満たすテストを定義していく test "feed should have the right posts" do

※毎回書いたほうがいい気がするので書いておきます※ 平文の部分をちょこちょこI18nで日本語化しているのですが その部分に関しては特に記述していなくてもたまにコードが違ったりしています。 t(‘.hogehoge’)って部分です どうぞお気になさらず。 13.4 マイクロポストの画像投稿 マイクロポストの基本的な操作は実装できたが 応用として画像付きのマイクロポストを投稿できるようにしていく。 開発環境用のβ版を実装 ↓ 改善 ↓ 本番環境用の完成版を実装 .gitignoreの編集 開発環境でアップロードされた画像がgitにpushされないように.gitignoreを編集しておく （本文では最後の方に出てくるけど、途中でもコミットするのであれば設定しておく🐫） . . . # アップロードされたテスト画像を無視する /public/uploads ※隠しファイルになっているので注意 画

13.2 マイクロポストを表示する マイクロポストの表示予定図はこんな感じ RoRT本文参照です ここでは、Twitterのような独立したマイクロポストのindexページは作らずに、図 13.4のモックアップに示したように、ユーザーのshowページで直接マイクロポストを表示させることにします。ユーザープロフィールにマイクロポストを表示させるため、最初に極めてシンプルなERbテンプレートを作成します。次に、10.3.2のサンプルデータ生成タスクにマイクロポストのサンプルを追加して、画面にサンプルデータが表示されるようにしてみます。 13.2.1 マイクロポストの描画 ユーザーのプロフィール画面 (show.html.erb) に、そのユーザーのマイクロポストを表示させたり、そのユーザーが投稿した総数も表示させたりしていく →一旦データベースをリセット＆サンプルデータの再生成 $ rails

ユーザーが短いメッセージを投稿できる機能を作っていく →「マイクロポストリソース」を追加していく Micropostデータモデルを作成し、Userモデルとhas_manyおよびbelongs_toメソッドを使って関連付けを行い、さらに、結果を処理し表示するために必要なフォームとその部品を作成します (13.4で画像のアップロードも実装します)。 因みに（？）14章ではユーザーをフォローするという概念を導入してマイクロポストのフィードを受け取れるようにする（Twitterのミニクローンの完成！） 13.1 Micropostモデル Micropostモデルを作成する 今回のマイクロポストモデルは完全にテストされ、デフォルトの順序を持ち、また親であるユーザーが破棄された場合には自動的に破棄されるようにします。 （2章のtoy-appと違って～的なお話) ではブランチを作成して作業開始！ $ g

※毎回書いたほうがいい気がするので書いておきます※ 平文の部分をI18nでちょこちょこ日本語化しているのですが その部分に関しては特に記述していなくてもたまにコードが違ったりしています。 t(‘.hogehoge’)って部分です どうぞお気になさらず。 12.2 パスワード再設定のメール送信 パスワードの再設定に関するメールの部分を作っていく 11章でUserメイラーを生成した際にデフォルトのpassword_resetメソッドなどもまとめて生成されているので それを使って定義していく！ 12.2.1 パスワード再設定のメールとテンプレート 11.3.3で行ったリファクタリングと同様の作業を行っていく 最初にUserメイラーにpassword_resetメソッドを作成し (リスト 12.7)、続いて、テキストメールのテンプレート (リスト 12.8) とHTMLメールのテンプレート (リス

11.3 アカウントを有効化する メールが生成できるようになったのでAccountActivationsコントローラのeditアクションを書いていく。 テストも書いて、しっかりテストできていたらUserモデルにコードを移していく (リファクタリング) authenticated?メソッドの抽象化 有効化トークンとメールはそれぞれparams[:id]とparams[:email]で参照できるので 次のようなコードでユーザーを検索して承認する user = User.find_by(email: params[:email]) if user && user.authenticated?(:activation, params[:id]) (この後、上の式に論理値を１つ追加します。何が追加されるか考えてみましょう。) （→予想：アカウントが有効化されていないことを確認する論理値　#とは　🤔

11.2 アカウント有効化のメール送信 準備ができたので、アカウント有効化メールに必要なコードを追加していく このメソッドではAction Mailerライブラリを使ってUserのメイラーを追加します。このメイラーはUsersコントローラのcreateアクションで有効化リンクをメール送信するために使います。 Action Mailerライブラリとなはんぞ Railsを使ってメールを送信する仕組み（雑） アクションやviewからメールを送信できるようになる メイラーの動作はコントローラのアクションと似ているしテンプレートはviewに似ている 詳しくはこちらとか→Railsガイド｜Action Mailer の基礎 11.2.1 送信メールのテンプレート メイラーもrails generateで生成する $ rails generate mailer UserMailer account_ac

11章でやること アカウントを有効化するためのメール認証システムを作る！ ユーザーの初期状態は「有効化されていない」(unactivated) にしておく。 ユーザー登録が行われたときに、有効化トークンと、それに対応する有効化ダイジェストを生成する。 有効化ダイジェストはデータベースに保存しておき、有効化トークンはメールアドレスと一緒に、ユーザーに送信する有効化用メールのリンクに仕込んでおく ユーザーがメールのリンクをクリックしたら、アプリケーションはメールアドレスをキーにしてユーザーを探し、データベース内に保存しておいた有効化ダイジェストと比較することでトークンを認証する。 ユーザーを認証できたら、ユーザーのステータスを「有効化されていない」から「有効化済み」(activated) に変更する。 うむわからん！ こうやって書くとよくわからないけど、 パスワードや記憶トークンの仕組みと似た

10.4 ユーザーを削除する RESTに準拠した正統なアプリケーションとなる為に、最後の一つ、destroy機能を実装していく！ 削除権限を持つ管理 （admin）ユーザーのクラスを作成し→ユーザーを削除するためのリンクを追加し→destroyアクションを実装する 見本はこちら→RoRT本文 10.4.1 管理ユーザー 論理値をとるadmin属性をUserモデルに追加する　→　自動的に論理値を返すadmin?メソッドも使えるようになる　→　管理ユーザーの状態をテストできる admin属性をUserモデルに追加 属性の型をbooleanと指定してマイグレートファイルを作る boolean型 → 論理値を取る型 $ rails generate migration add_admin_to_users admin:boolean Running via Spring preloader in

10.3 すべてのユーザーを表示する indexアクションを追加してユーザー一覧を表示させる →データベースにサンプルデータを追加する方法 →ページネーション（pagination=ページ分割）の方法 見本はこちら　→　RoRT本文 10.3.1 ユーザーの一覧ページ ユーザーindexページはログインユーザーしか表示できないようにする indexアクションのリダイレクト UsersControllerTestにindexアクションが正しくリダイレクトするかを検証するテストを定義していく require 'test_helper' class UsersControllerTest < ActionDispatch::IntegrationTest # テストユーザーを設定 def setup @user = users(:michael) @other_user = users(:arc

10.2 認可 ウェブアプリケーションの文脈では、認証 (authentication) はサイトのユーザーを識別することであり、認可 (authorization) はそのユーザーが実行可能な操作を管理することです。 現状ではログインしていないユーザーでもどのユーザー情報でも編集できてしまうため ユーザーにログインを要求し、自分以外のユーザー情報を変更できないように制御する →セキュリティ上の制御機構をセキュリティモデルと呼ぶ やっていくこと ログインしていないユーザーが保護されたページにアクセスしようとした場合ログインページに転送してメッセージを表示させる さらに、許可されていないページにアクセス済のユーザーがいたらルートURLにリダイレクトさせる 10.2.1 ユーザーにログインを要求する Usersコントローラの中でbeforeフィルターを使ってユーザーにログインを要求する bef

10章でやること ユーザーの更新・表示・削除 →未実装のedit、update、index、destroyアクションを加えてRESTアクションを完成させる ユーザーが自身でプロフィールを更新できるようにする ログイン済の場合ユーザー一覧を表示できるようにする 管理ユーザーを作成し、管理ユーザーのみユーザーを削除できるようにする 10.1 ユーザーを更新する ユーザー情報を編集するパターンは新規ユーザーの作成を参考に進められる 新規ユーザー用のビューを出力するnewアクションと同じようにして、ユーザーを編集するためのeditアクションを作成すればよいのです。同様に、POSTリクエストに応答するcreateの代わりに、PATCHリクエストに応答するupdateアクションを作成します ただし、ユーザー登録は誰でもできるけどユーザー情報の更新はそのユーザー自身に限られる！ →8章の承認機構を使って

9.3 [Remember me] のテスト 動作をテストで確認できるようにしておくことが重要です！！ →ユーザーを永続化するコードのメイン部分は未だ全くテストされていないのであった 9.3.1 [Remember me] ボックスをテストする log_in_asヘルパーメソッドを定義 ユーザーが記憶されるためにはログインが必要なので テスト内でユーザーがログインできるようにするためのする →単体テスト・統合テストそれぞれで使えるように定義していく ・ ・ ・ class ActiveSupport::TestCase # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order. fixtures :all include ApplicationHelper # Add more helpe

9章でやる事 （任意で）ユーザーのログイン情報を記憶しておけるようにする →remember me機能 永続cookieを使ってremember me機能を実現 9.1 Remember me 機能 ブラウザを閉じた後でもログイン状態を有効にする[remember me] 機能を実装していく この機能を使うと、ユーザーが明示的にログアウトを実行しない限り、ログイン状態を維持することができるようになります。 git checkout -b advanced-login 9.1.1 記憶トークンと暗号化 8.2で行ったsessionメソッドを使ってユーザーIDを保存する方法ではブラウザを閉じるとユーザー情報が消えてしまう。 本節では、セッションの永続化の第一歩として記憶トークン (remember token) を生成し、cookiesメソッドによる永続的cookiesの作成や、安全性の高い記

8.2 ログイン 有効な値の送信があった場合にログインできるようにする！ →cookieを使った一時セッションでログイン →ブラウザを閉じると自動的に期限切れになるようにする セッションを実装するには、様々なコントローラやビューでおびただしい数のメソッドを定義する必要があります。（中略）Sessionsコントローラ (8.1.1) を生成した時点で既にセッション用ヘルパーモジュールも (密かに) 自動生成されています。さらに、Railsのセッション用ヘルパーはビューにも自動的に読み込まれます。 ApplicationコントローラにSessionヘルパーモジュールを読み込ませてどのコントローラからでも使えるようにする class ApplicationController < ActionController::Base protect_from_forgery with: :excepti

7.5 プロのデプロイ 実際に動かせるアプリのデプロイ！ 準備として現時点までをmasterブランチにマージしておく 7.5.1 本番環境でのSSL 本章で開発したユーザー登録フォームで送信すると、名前やメールアドレス、パスワードといったデータがネットワーク越しに流されていきます。実は、このようなネットワークに流れるデータは途中で捕捉できるため、扱いには注意が必要です。これはサンプルアプリケーションの本質的なセキュリティ上の欠陥です。そしてこれを修正するためにSecure Sockets Layer (SSL)を使います 12。これはローカルのサーバからネットワークに流れる前に、大事な情報を暗号化する技術です。 ・ ・ ・ # Force all access to the app over SSL, use Strict-Transport-Security, and use secur

7.4 ユーザー登録成功 新規ユーザーのデータが有効な場合、データベースに保存できるようにする 7.4.1 登録フォームの完成 users_controller.rbにコードを追加 ↓ createアクションに対応するテンプレートを作るのではなく 新しく作成されたユーザーの詳細画面にリダイレクトするように設定 def create @user = User.new(user_params) if @user.save #redirect_to user_url(@user)と同意 #ユーザーの詳細画面に自動で変換してくれる redirect_to @user else render 'new' end end ・ ・ ・ 演習 有効な情報を送信し、ユーザーが実際に作成されたことを、Railsコンソールを使って確認してみましょう。 リスト 7.28を更新し、redirect_to user_

番外編では本編からちょっと外れた話なんかを書いていきます エラーメッセージを日本語化したい！ だって英語で言われてもわからないじゃん？（？ なので 本文でバリデーションエラーのメッセージ云々が出てきたところで チャレンジしていきたいと思います。 作業用に、現状から新しくブランチ（i18n）を切ります （add-i18nとかのが良かったかもね？） （生やす場所ももっと考えた方が良かったかもね？） （masterから生やすとかね） RailsガイドのRails 国際化 (i18n) APIのページ↓