[best practice] security.rst をひと通り和訳

Author: kseta

best_practices/security.rst

@@ -1,9 +1,20 @@
+セキュリティ
 Security
 ========
 
+認証とファイアウォール (i.e. Getting thw User's Credentials)
 Authentication and Firewalls (i.e. Getting the User's Credentials)
 ------------------------------------------------------------------
 
+
+思いのままの手段と様々なデータソースからユーザ情報をロードしユーザの認証を Symfony に
+設定することができます。
+とても難解なテーマですが、`Security Cookbook Section`_ には
+これについてのたくさんの情報が記載されています。
+
+``security.yml`` の初期設定の ``firewalls`` キーの下に認証を設定します。
+
+
 You can configure Symfony to authenticate your users using any method you
 want and to load user information from any source. This is a complex topic,
 but the `Security Cookbook Section`_ has a lot of information about this.
@@ -13,30 +24,52 @@ primarily under the ``firewalls`` key.
 
 .. best-practice::
 
+    正規に許可された２つのことなる認証システムとユーザが無い限り
+    (e.g. メインとなるサイトと API のためだけのトークンシステムのためのログイン)、
+    ``anonymous`` のキーを有効にしたたったひとつのファイヤーウォールを設けることを推奨します。
+
     Unless you have two legitimately different authentication systems and
     users (e.g. form login for the main site and a token system for your
     API only), we recommend having only *one* firewall entry with the ``anonymous``
     key enabled.
 
+
+ほとんどのアプリケーションで認証システムとユーザのセットはひとつしかありません。
+このため、ひとつのファイヤーウォールの設定だけで事足ります。
+もちろん サイトの API と WEB を分けたいときなどの例外もありますが、
+シンプルに考えていくことが重要です。
+
 Most applications only have one authentication system and one set of users.
 For this reason, you only need *one* firewall entry. There are exceptions
 of course, especially if you have separated web and API sections on your
 site. But the point is to keep things simple.
 
+なお、ファイヤーウォールの下では ``anonymous`` キーを利用するべきです。
+サイトの異なるセクション (または 全てのセクションのようなもの) にユーザが
+ログインすることが必要となった場合は ``access_control`` エリアを利用します。
+
 Additionally, you should use the ``anonymous`` key under your firewall. If
 you need to require users to be logged in for different sections of your
 site (or maybe nearly *all* sections), use the ``access_control`` area.
 
 .. best-practice::
 
-    Use the ``bcrypt`` encoder for encoding your users' passwords.
+    ユーザのパスワードのエンコーディングには ``bcrypt`` エンコーダーを利用する。
+
+ユーザがパスワードを持つ場合、SHA-512 の代わりに ``bcrypt`` エンコーダーを利用することを推奨します。
+``bcrypt`` のアドバンテージは、**ソルト** の値がレインボーテーブルアタックから守り
+ブルートフォースアタックを遅延することができることです。
 
 If your users have a password, then we recommend encoding it using the ``bcrypt``
 encoder, instead of the traditional SHA-512 hashing encoder. The main advantages
 of ``bcrypt`` are the inclusion of a *salt* value to protect against rainbow
 table attacks, and its adaptive nature, which allows to make it slower to
 remain resistant to brute-force search attacks.
 
+この方針で、
+データベースからユーザをロードするログインフォームを利用する認証を
+アプリケーションにセットアップする設定は以下となります。
+
 With this in mind, here is the authentication setup from our application,
 which uses a login form to load users from the database:
 
@@ -66,41 +99,66 @@ which uses a login form to load users from the database:
 
 .. tip::
 
+    プロジェクトのソースコードにそれぞれの部位を説明するコメントをもつ。
     The source code for our project contains comments that explain each part.
 
+
+認証 (i.e アクセスの拒否)
 Authorization (i.e. Denying Access)
 -----------------------------------
 
+Symfony は認証を実装するために、 `security.yml`_ に ``access_control`` を設定する、
+ ``security.context`` のサービスディレクトリに `@Security annotation <best-practices-security-annotation>` と
+ `isGranted <best-practices-directy-isGranted>` を使うなどのいくつかの手段を提供しています。
+
 Symfony gives you several ways to enforce authorization, including the ``access_control``
 configuration in `security.yml`_, the :ref:`@Security annotation <best-practices-security-annotation>`
 and using :ref:`isGranted <best-practices-directy-isGranted>` on the ``security.context``
 service directly.
 
 .. best-practice::
 
+    * 広範囲の URL パターンをプロテクトするためには ``access_control`` を利用する。
+    * いつでも可能なときは ``@Security`` アノテーションを利用する。
+    * より複雑な状況の場合はいつでも、
+      ``security.context`` サービスででセキュアなディレクトリをチェックする。
+
     * For protecting broad URL patterns, use ``access_control``;
     * Whenever possible, use the ``@Security`` annotation;
     * Check security directly on the ``security.context`` service whenever
       you have a more complex situation.
 
+認証ロジックを一箇所に集中させる様々な方法があります。
+例えば、カスタムセキュリティボーターや ACL を利用したものです。
 There are also different ways to centralize your authorization logic, like
 with a custom security voter or with ACL.
 
 .. best-practice::
 
+    * Fine-grained 制限のために、カスタムセキュリティボーターを定義する。
+    * 管理者インターフェースを経由したあらゆるユーザの
+      あらゆるのオブジェクトへのアクセスを制限するために Symfony ACL を利用する。
+
     * For fine-grained restrictions, define a custom security voter;
     * For restricting access to *any* object by *any* user via an admin
       interface, use the Symfony ACL.
 
 .. _best-practices-security-annotation:
 
+@Security アノテーション
 The @Security Annotation
 ------------------------
 
+controller-by-controller の原則にしたがってアクセスをコントロールするために、
+``@Secury`` アノテーションを可能な限り利用します。
+この方法は、可読性が高く、矛盾なくそれぞれのアクションに付与することができます。
 For controlling access on a controller-by-controller basis, use the ``@Security``
 annotation whenever possible. It's easy to read and is placed consistently
 above each action.
 
+このアプリケーションにおいて、新しいポストを作成するための ``ROLE_ADMIN`` が必要です。
+``@Security`` を利用して、このように実装できます。
+
 In our application, you need the ``ROLE_ADMIN`` in order to create a new post.
 Using ``@Security``, this looks like:
 
@@ -121,9 +179,16 @@ Using ``@Security``, this looks like:
         // ...
     }
 
+Expression で複雑なセキュリティの制限の記述する
 Using Expressions for Complex Security Restrictions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+セキュリティロジックがかなり複雑な場合は、
+``@Security`` の内部で `expression`_ を利用できます。
+例えば、
+``Post`` オブジェクトの ``getAuthorEmail`` メソッドの返り値とメールアドレスが一致したときのみ
+コントローラーへのアクセスを許可したい場合は以下のように実装できます。
+
 If your security logic is a little bit more complex, you can use an `expression`_
 inside ``@Security``. In the following example, a user can only access the
 controller if their email matches the value returned by the ``getAuthorEmail``
@@ -144,10 +209,18 @@ method on the ``Post`` object:
         // ...
     }
 
+``Post`` オブジェクトとそれに与えられる ``$post`` という引数のための
+自動的なクエリ`PramConverter`_ の利用が必須であることに注意してください。
+
 Notice that this requires the use of the `ParamConverter`_, which automatically
 queries for the ``Post`` object and puts it on the ``$post`` argument. This
 is what makes it possible to use the ``post`` variable in the expression.
 
+この方法は有名な決定を持っています。
+アノテーションによる expression は他のアプリケーションでは容易に再利用できません。
+著者のみが閲覧できるテンプレートのリンクを追加したい場合を想像してください。
+Twig を利用して expression を再び記述することがすぐ思い浮かぶでしょう。
+
 This has one major drawback: an expression in an annotation cannot easily
 be reused in other parts of the application. Imagine that you want to add
 a link in a template that will only be seen by authors. Right now you'll
@@ -159,6 +232,10 @@ need to repeat the expression code using Twig syntax:
         <a href=""> ... </a>
     {% endif %}
 
+十分にシンプルなロジックの場合、最も簡単な解決手段は
+与えられたユーザがその投稿の著者であるかをチェックする新しい関数を
+ ``Post`` エンティティに追加することです。
+
 The easiest solution - if your logic is simple enough - is to add a new method
 to the ``Post`` entity that checks if a given user is its author:
 
@@ -182,6 +259,8 @@ to the ``Post`` entity that checks if a given user is its author:
         }
     }
 
+これで、この関数をテンプレートとセキュリティの記述のどちらでも再利用できます。
+
 Now you can reuse this method both in the template and in the security expression:
 
 .. code-block:: php
@@ -206,9 +285,15 @@ Now you can reuse this method both in the template and in the security expressio
 
 .. _best-practices-directy-isGranted:
 
+@Security なしに権限をチェックする
 Checking Permissions without @Security
 --------------------------------------
 
+これまでの例は、
+``post`` という変数にアクセスできる記述を提供してくれる :ref:`ParamConverter <best-practices-paramconverter>` を
+利用する場合のみ動作します。
+これを利用しない場合やより進んだユースケースの場合は、PHP で同様のセキュリティチェックができます。
+
 The above example with ``@Security`` only works because we're using the
 :ref:`ParamConverter <best-practices-paramconverter>`, which gives the expression
 access to the a ``post`` variable. If you don't use this, or have some other
@@ -235,14 +320,23 @@ more advanced use-case, you can always do the same security check in PHP:
         // ...
     }
 
+セキュリティボーター
 Security Voters
 ---------------
 
+セキュリティロジックが複雑で ``isAuthor()`` のようなメソッドに局所化できない場合、
+カスタムボーターを利用することができます。
+これらは `ACL's`_ よりもかなり簡単な方法かつほぼ全てのケースに柔軟に対応できます。
+
 If your security logic is complex and can't be centralized into a method
 like ``isAuthor()``, you should leverage custom voters. These are an order
 of magnitude easier than `ACL's`_ and will give you the flexibility you need
 in almost all cases.
 
+
+まずはじめに、voter クラスを作成します。以下の例では、これまでと同じ ``getAuthorEmail`` ロジックを
+実装した voter について示します。
+
 First, create a voter class. The following example shows a voter that implements
 the same ``getAuthorEmail`` logic you used above:
 
@@ -287,6 +381,7 @@ the same ``getAuthorEmail`` logic you used above:
         }
     }
 
+アプリケーションでセキュリティボータを有効にするために新しいサービスを定義します。
 To enable the security voter in the application, define a new service:
 
 .. code-block:: yaml
@@ -300,6 +395,7 @@ To enable the security voter in the application, define a new service:
             tags:
                - { name: security.voter }
 
+ここで ``@Security`` アノテーションと共に voter を利用してみます。
 Now, you can use the voter with the ``@Security`` annotation:
 
 .. code-block:: php
@@ -313,6 +409,9 @@ Now, you can use the voter with the ``@Security`` annotation:
         // ...
     }
 
+このディレクトリを ``security.context`` と共に使うことも可能です。
+また、コントローラーでより簡潔なショートカットを経由することも可能です。
+
 You can also use this directly with the ``security.context`` service, or
 via the even easier shortcut in a controller:
 
@@ -330,20 +429,31 @@ via the even easier shortcut in a controller:
         }
     }
 
+さらに学ぶためには
 Learn More
 ----------
 
+Symfony のコミュニティによって開発された `FOSUserBundle`_ は Symfony2 における
+データベースによるユーザシステムのサポートを追加しました。
+これはユーザの登録やパスワードを忘れた時の機能などの共通のタスクも取り扱っています。
+
 The `FOSUserBundle`_, developed by the Symfony community, adds support for a
 database-backed user system in Symfony2. It also handles common tasks like
 user registration and forgotten password functionality.
 
+`Remember Me feature`_ を有効にすることによってユーザを長期期間ログインさせておくことも可能です。
 Enable the `Remember Me feature`_ to allow your users to stay logged in for
 a long period of time.
 
+カスタマーサポートを提供したとき、問題を再現するために異なるユーザでアプリケーションにアクセス
+することがたびたび必要になります。
+Symfony は `impersonate users`_ の機能を提供しています。
 When providing customer support, sometimes it's necessary to access the application
 as some *other* user so that you can reproduce the problem. Symfony provides
 the ability to `impersonate users`_.
 
+Symfony でサポートしていないユーザのログインメソッドを利用する場合、
+`your own user provider`_ と `your own authentication provider`_ で開発することができます。
 If your company uses a user login method not supported by Symfony, you can
 develop `your own user provider`_ and `your own authentication provider`_.