(詳細は私の名前をGoogleで検索してみてください)。乗り換えることができました。チュートリアルという本です。関連の本を参考にしてきましたが、真の決定版と呼べるものは本書をおいて他にありません。流」で行われています。最初のうちは慣れるまでに時間がかかりましたが、この本を終えた今、ついにこれこそが自然な方式だと感じられるまでになりました。全編を通して実践しています。実例を使ってここまで分かりやすく解説された本は、本書が初めてでしょう。実例に含めている点です。このような、実際の開発現場で使わているツールもチュートリアルに含まれているため、読者は、まるで実際のプロジェクトの開発プロセスを体験しているかのような感覚が得られるはずです。それでいて、それぞれの実例が独立したセクションになっているのではなく、そのどれもがチュートリアルの内容と見事に一体化しています。本書は、筋道だった一本道の物語のようになっています。チュートリアルを3日間かけて一気に読破しました1。最初から最後まで、途中を飛ばさずにやるのが一番効果的で有益な読み方です。3分のTEDの動画「社会運動をどうやって起こすか」を観たことがある方もいるのではないでしょうか。その方からの推薦の言葉です。多くを参考にさせてもらっています。協力と本書への支援も含め、感謝したいと思います。氏にも謝意を表したく思います。彼女が野球の試合に連れて行ってくれる限り、私は本を書き続けるでしょう。方々、ありがとうございました。最後に、ここに書ききれないほど多くの読者からバグ報告や提案を頂きました。ご協力いただいた皆様のおかげで、本書の完成度をとことんまで高めることができました。Donahoe、日々のチュートリアルの制作をサポートしてくれてありがとう。最後に、たくさんの読者の皆さん、そして、ここに挙げきれないほど多いコントリビューターのみんな、バグ報告や提案をしてくれてありがとう。彼ら/彼女らの多くの手助けに、最高の感謝を。開発を学ぶときによく参考にされる本の著者です。教育系ウェブサイトの創業者でもあります。ベースのSNSプラットフォーム「Insoshi」の開発にも携わっていました。ハーバード大学卒業後、カリフォルニア工科大学で物理学博士号を取得。ライセンスの元で提供されています。「すべてのソースコード」とは、Railsチュートリアル内で題材としている「Railsアプリケーションのソースコード」を指します。「Railsチュートリアル」という教材は上記ライセンスで提供されていないのでご注意ください。商用でRailsチュートリアルをご利用する場合はお問い合わせページからご連絡ください。実際には数週間〜数ヶ月をかけて読むのが一般的です。うち、これまで未実装だったedit、update、index、destroyアクションを加え、RESTアクションを完成させます。本章ではまず、ユーザーが自分のプロフィールを自分で更新できるようにします。ついて説明する自然なキッカケになります。(もちろん認証を要求します)。導入する動機にもなります。最後に、ユーザーを削除し、データベースから完全に消去する機能を追加します。ユーザーの削除はどのユーザーにも許可できるものではないので、管理ユーザーという特権クラスを作成し、このユーザーにのみ削除を許可するようにします。新規ユーザー用のビューを出力するnewアクションと同じようにして、ユーザーを編集するためのeditアクションを作成すればよいのです。最大の違いは、ユーザー登録は誰でも実行できますが、ユーザー情報を更新できるのはそのユーザー自身に限られるということです。使ってこのアクセス制御を実現できます。最初に、いつものようにupdating-usersトピックブランチを作成しましょう。編集フォームまずは編集フォームから始めます。10.1のモックアップを動くページにするためには、Usersコントローラにeditアクションを追加して、それに対応するeditビューを実装する必要があります。editアクションの実装から始めますが、ここではデータベースから適切なユーザーデータを読み込む必要があります。(ユーザーのidが1の場合)。ユーザーのidはparams[:id]変数で取り出すことができるのを思い出してください。10.1のコードを使えばそのユーザーを指定できるということです。(このファイルは手動で作成する必要があります)。7.15と極めて似通っていることに注目してください。重複が多いということは、それらのコードの繰り返しをパーシャルにまとめることができるということです。(10.1.1.1)。7.3.3で導入したerror_messagesパーシャルを再利用しています。(ただしtarget="_blank"にはセキュリティ上の小さな問題もあります。詳しくは10.1.1.1の演習で見ていきましょう)。10.2の"Name"や"Email"の部分を見ると、Railsによって名前やメールアドレスのフィールドに値が自動的に入力されていることがわかります。これらの値は、@user変数の属性情報から引き出されています。.</form>次の入力フィールドに隠し属性があることに注目してください。送信できないので、RailsはPOSTリクエストと隠しinputフィールドを利用してPATCHリクエストを「偽造」しています2。ここでもう1つ微妙な点を指摘しておきたいと思います。7.15のコードと完全に同じです。すると、Railsはどうやって新規ユーザー用のPOSTリクエストとユーザー編集用のPATCHリクエストを区別するのでしょうか。Recordのnew_record?論理値メソッドを使って区別できるからです。falseRailsは、form_for(@user)を使ってフォームを構成すると、@user.new_record?がtrueのときにはPOSTを、falseのときにはPATCHを使います。仕上げに、ナビゲーションバーにあるユーザー設定へのリンクを更新します。9.9で定義したcurrent_userというヘルパーメソッドを使うと、実装が簡単です。先ほど触れたように、target="_blank"で新しいページを開くときには、セキュリティ上の小さな問題があります。それは、リンク先のサイトがHTMLドキュメントのwindowオブジェクトを扱えてしまう、という点です。サイトのような、悪意のあるコンテンツを導入させられてしまう可能性があります。Gravatarのような著名なサイトではこのような事態は起こらないと思いますが、念のため、このセキュリティ上のリスクも排除しておきましょう。属性に、"noopener"と設定するだけです。10.2で使ったGravatarの編集ページへのリンクにこの設定をしてみましょう。(コードの重複を取り除いてみましょう)。3.4.3で使ったprovideメソッドを使うと、重複を取り除けます3。7.27の演習課題を既に解いている場合、この演習課題をうまく解けない可能性があります。うまく解けない場合は、既存のコードのどこに差異があるのか考えながらこの課題に取り組んでみましょう。10.5に渡してみるでしょう。本項では、7.3のユーザー登録に失敗したときと似た方法で、編集に失敗した場合について扱っていきます。使って送信されたparamsハッシュに基いてユーザーを更新します。無効な情報が送信された場合、更新の結果としてfalseが返され、elseに分岐して編集ページをレンダリングします。このパターンは以前にも出現したことを覚えているでしょうか。更新に成功した場合を扱う。endendupdate_attributesへの呼び出しでuser_paramsを使っていることに注目してください。Parametersを使ってマスアサインメントの脆弱性を防止しています。編集フォームから有効でないユーザー名やメールアドレス、パスワードを使って送信した場合、編集に失敗することを確認してみましょう。編集失敗時のテスト10.1.2では編集フォームの失敗時を実装しました。3.3で説明したテストのガイドラインに従って、エラーを検知するための統合テストを書いていきましょう。いつものように、統合テストを生成するところから始めます。10.9のテストでは、まず編集ページにアクセスし、editビューが描画されるかどうかをチェックしています。その後、無効な情報を送信してみて、editビューが再描画されるかどうかをチェックします。ここで、PATCHリクエストを送るためにpatchメソッドを使っていることに注目してください。これはgetやpost、deleteメソッドと同じように、HTTPリクエストを送信するためのメソッドです。greenになるはずです。10.9のテストに1行追加し、正しい数のエラーメッセージが表示されているかテストしてみましょう。errors.」というテキストを精査してみましょう。TDDで編集を成功させる今度は編集フォームが動作するようにしましょう。プロフィール画像の編集は、画像のアップロードをGravatarに任せてあるので、既に動作するようになっています。10.4のようにGravatarを編集できます。それ以外の機能の実装にとりかかりましょう。(写真は誰かさん)そろそろ、より快適にテストをするためには、アプリケーション用のコードを「実装する前に」統合テストを書いた方が便利だと気付いた読者もいるかもしれません。Tests)」として呼ばれていて、ある機能の実装が完了し、受け入れ可能な状態になったかどうかを決めるテストとして知られています。実際に体験してもらうために、今回はテスト駆動開発を使ってユーザーの編集機能を実装してみましょう。(今回は有効な情報を送信するように修正します)。次に、flashメッセージが空でないかどうかと、プロフィールページにリダイレクトされるかどうかをチェックします。データベース内のユーザー情報が正しく変更されたかどうかも検証します。10.11に示します。10.11のパスワードとパスワード確認が空であることに注目してください。パスワードを入力せずに更新できると便利です。6.1.5で紹介した@user.reloadを使って、データベースから最新のユーザー情報を読み込み直して、正しく更新されたかどうかを確認している点にも注目してください。先にテストを書くので、効果的なユーザー体験について考えるようになります。redのままになっているはずです。greenになるためには、パスワードのバリデーションに対して、空だったときの例外処理を加える必要があります。10.13によって、新規ユーザー登録時に空のパスワードが有効になってしまうのかと心配になるかもしれませんが、安心してください。新規ユーザー登録時に有効になることはありません。(7.3.3)、これで解決できました。なったかどうか確かめてみてください。実際に編集が成功するかどうか、有効な情報を送信して確かめてみましょう。実際に編集フォームからメールアドレスを変更して、確認してみましょう。そのユーザーが実行可能な操作を管理することです。第8章で認証システムを構築したことで、認可のためのシステムを実装する準備もできました。10.1のeditアクションとupdateアクションはすでに完全に動作していますが、セキュリティ上の大穴が1つ空いています。ユーザー情報を編集できてしまうのです。(こういったセキュリティ上の制御機構をセキュリティモデルと呼びます)。10.2.1では、ログインしていないユーザーが保護されたページにアクセスしようとした際のケースについて対処していきます。いったケースはアプリケーションを使っていると普通に起こることなので、ログインページに転送して、そのときに分かりやすいメッセージも表示するようにしましょう。