Djangoまとめ
Djangoビギナーズブックで重要だったところをまとめていきます。
◆p.35 エラーページの意義
Django などの Web フレームワークには、リクエストされたファイルが見つからないとき（＝存在しないファイルを求められたとき）に、標準状態でそのことを示すページが用意されています。
一般的な Web サーバの一部には「index.html が配置されていないディレクトリを URL で参照されたとき、ディレクトリの中身を一覧で表示してしまう」という仕様があるのですが、Django などのフレームワークを活用することで、不用意にファイルが表示されてしまうのを防ぐことができます。
しかしながら、標準の状態では「Django を使っている」ことがユーザーに分かってしまうので、例えば Web フレームワークにセキュリティ上の問題が見つかった際に、その問題をピンポイントで突くようなサイバー攻撃を受けてしまう可能性もあるでしょう。そのため、404 エラーの際に表示される HTML ファイルは、開発者の側で「Django などの特定の Web フレームワークを使っているとわからないように」変更しておくことも多いです。
◆p.43 テンプレートの意義
Web フレームワークの大きな意義として、事前に「データを入れる位置だけを決めた HTML ファイル」を用意しておき、そこにフレームワーク内で利用している変数などを入れ込んで表示することができる、というものがあります。
このような方式の下では HTML ファイルをプログラムと切り離した領域に置けるため、HTML / CSS 部分のみを編集する際にプログラムファイルを編集してしまい動作不能になるケースが少ない / プログラムファイルとの協調を考える必要がほとんどない、という利点があります。
◆p.53 URL のハードコーディング
プログラムの中に直接値や文字列を記述せず、一度変数・定数にその値や文字列を代入してから「変数・定数」を使うようにすることで、開発プロセスの中でその値や文字列に変更が生じた際、変更箇所を最小限に抑えられる / 変更漏れなどのミスを生じないようにすることができます。
特にファイルパスや「何回処理をするか」を決める値などは、頻繁に変更が加わる可能性があるため、開発規模がさほど大きくなくハードコーディングにしなくても良さそうだ、と考えていても一度何らかの定数に落とし込んでおくことが重要です。
◆ p.78タイムゾーン
一般的に、Web サービスの開発においては複数の国をまたがっての利用を想定することが望ましいとされます。ユーザーの「利用国」が多様なものとなることを前提とした場合に、開発者側が取扱いに注意を要する要素の代表格に「タイムゾーン」の取り扱いがあります。
例として、異なるタイムゾーンに属するユーザーが、同じシステムに対して何らかの処理 / データの登録を行うことを考えます。ここで、「それぞれの環境（タイムゾーン）における時間」を DB に登録した場合、ユーザーの属するタイムゾーンにより、登録されたデータのソート順などが変動してしまい、結果として正しくない処理が行われてしまう可能性があるのです。このような問題を避けるため、DB に「時間」の情報を記録する際、あるいは時間の情報を比較する際などには、ある 1 つのタイムゾーンに合わせた時間（代表的なものでは UTC：世界標準時）により処理・記録を行うことが望ましいとされます。もちろん、DB に記録した時間の情報をユーザーに表示する際には、それぞれの国のタイムゾーンに合わせた表示に直してから表示を行う必要があることを忘れないようにしよう。
◆ p.140 データの送信
ここで取り上げられているフォーム要素は、一見すると HTML によるフォームの表現とほとんど共通しているように見えますが、{% csrf_token %} の 1 行が含まれていることに注意しましょう。
この 1 行は、「クロスサイトリクエストフォージェリ：CSRF」という Web アプリケーションの脆弱性を利用した攻撃（参考資料： https://www.trendmicro.com/ja_jp/security-intelligence/research-reports/threat-solution/csrf.html ）を防止するために極めて重要なものです。この 1 行が生成する HTML コードやその意味など、詳細はテキストの p.145 - p.147 を参照、Django に限らず、Web アプリケーション向けのフレームワークであれば、このようなセキュリティリスクを Web フレームワークの標準機能が未然に防いでいる箇所があるということを覚えておくと良い。
なお、CSRF の他にも、Web アプリケーションを構築する上で考慮するべきセキュリティリスクは多く存在します。代表的なものが収載された Web ページの参考資料： http://gihyo.jp/dev/serial/01/javascript-security/0001
◆ p.154 入力値の検証
ユーザーからの入力を受け付ける（あるいは、ユーザーが何らかの情報を登録する）Web アプリケーションを構築する上では、ユーザーの入力した値を検証する機構があることが望ましいとされます。
Web フレームワークにおいてはこのような入力値の検証（バリデーション）の仕組みが標準で備わっているものがありますが、標準で備わっていない環境でサービスを開発する場合であっても、自力でプログラムを記述してバリデーションを行うようにすると良いでしょう。これは「空欄であるべきでない値（例：氏名など）が空欄だった時に、それを参照してエラーを起こすようなことのないようにする」という技術面の都合だけでなく、サービスを提供する提供者としての都合（例：顧客に問い合わせをしなければならない時に、電話番号が記入されていないと不便、など）もございます。
バリデーション
◆ p.143 GET と POST の違い
この記事が気に入ったらサポートをしてみませんか？