You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ka...@apache.org on 2006/12/24 02:12:41 UTC
svn commit: r489962 - /httpd/httpd/trunk/docs/manual/howto/auth.xml.ja
Author: kawai
Date: Sat Dec 23 17:12:41 2006
New Revision: 489962
URL: http://svn.apache.org/viewvc?view=rev&rev=489962
Log:
sync translation.
Modified:
httpd/httpd/trunk/docs/manual/howto/auth.xml.ja
Modified: httpd/httpd/trunk/docs/manual/howto/auth.xml.ja
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/howto/auth.xml.ja?view=diff&rev=489962&r1=489961&r2=489962
==============================================================================
--- httpd/httpd/trunk/docs/manual/howto/auth.xml.ja [iso-2022-jp] (original)
+++ httpd/httpd/trunk/docs/manual/howto/auth.xml.ja [iso-2022-jp] Sat Dec 23 17:12:41 2006
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding='iso-2022-jp' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 219484:479777 (outdated) -->
+<!-- English Revision: 479777 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -31,27 +31,63 @@
誰かが行きたい場所に行けるように、あるいは欲しい情報を
得ることができるようにするための全過程を指します。</p>
</summary>
-
+
<section id="related"><title>関連するモジュールとディレクティブ</title>
- <related>
- <modulelist>
- <module>mod_auth_basic</module>
- <module>mod_authn_file</module>
- <module>mod_authz_groupfile</module>
- <module>mod_authz_host</module>
- </modulelist>
-
- <directivelist>
- <directive module="mod_authz_host">Allow</directive>
- <directive module="mod_authz_groupfile">AuthGroupFile</directive>
- <directive module="core">AuthName</directive>
- <directive module="core">AuthType</directive>
- <directive module="mod_authn_file">AuthUserFile</directive>
- <directive module="mod_authz_host">Deny</directive>
- <directive module="core">Options</directive>
- <directive module="core">Require</directive>
- </directivelist>
- </related>
+<p>認証と承認の処理に関連する 3 種類のモジュールがあります。
+それぞれ少なくともひとつずつ必要です。</p>
+
+<ul>
+ <li>認証のタイプ (
+ <directive module="core">AuthType</directive> ディレクティブ参照)
+ <ul>
+ <li><module>mod_auth_basic</module></li>
+ <li><module>mod_auth_digest</module></li>
+ </ul>
+ </li>
+ <li>認証プロバイダ (
+ <directive module="mod_auth_basic">AuthBasicProvider</directive>,
+ <directive module="mod_auth_digest">AuthDigestProvider</directive> ディレクティブ参照)
+
+ <ul>
+ <li><module>mod_authn_anon</module></li>
+ <li><module>mod_authn_dbd</module></li>
+ <li><module>mod_authn_dbm</module></li>
+ <li><module>mod_authn_default</module></li>
+ <li><module>mod_authn_file</module></li>
+ <li><module>mod_authnz_ldap</module></li>
+ </ul>
+ </li>
+ <li>承認 (
+ <directive module="core">Require</directive> ディレクティブ参照)
+ <ul>
+ <li><module>mod_authnz_ldap</module></li>
+ <li><module>mod_authz_dbm</module></li>
+ <li><module>mod_authz_dbm</module></li>
+ <li><module>mod_authz_default</module></li>
+ <li><module>mod_authz_groupfile</module></li>
+ <li><module>mod_authz_host</module></li>
+ <li><module>mod_authz_owner</module></li>
+ <li><module>mod_authz_user</module></li>
+ </ul>
+ </li>
+</ul>
+
+ <p>これらのモジュールに加えて、<module>mod_authn_core</module>
+ と <module>mod_authz_core</module> があります。
+ この 2 つのモジュールは認証モジュールに共通なコアディレクティブを
+ 実装しています。</p>
+
+ <p><module>mod_authnz_ldap</module> は認証プロバイダと承認プロバイダの
+ 両方の機能を持っています。
+ <module>mod_authz_host</module> はホスト名、IP アドレスや
+ リクエストの特徴に基づいたアクセス制御を行いますが、
+ 認証プロバイダのシステムの一部ではありません。
+ mod_access との後方互換性のため、
+ 新しいモジュールの <module>mod_access_compat</module> があります。</p>
+
+ <p>様々なアクセス制御の行ない方については、
+ <a href="access.html">アクセス制御</a>の方法をご覧ください。</p>
+
</section>
<section id="introduction"><title>はじめに</title>
@@ -63,6 +99,11 @@
<p>この文書では、多くの人が採用するであろう、
ウェブサイトの一部分を保護する「一般的な」
方法についてカバーしています。</p>
+
+ <note><title>注意</title>
+ <p>データが本当に機密なのであれば、認証に加えてさらに
+ <module>mod_ssl</module> を使うと良いでしょう。</p>
+ </note>
</section>
<section id="theprerequisites"><title>準備</title>
@@ -99,14 +140,25 @@
これはそんなに難しくないので、この文書中で
ディレクトリ構造について知っておく必要がある場面では、
明らかになるようにします。</p>
+
+ <p><module>mod_authn_core</module> と <module>mod_authz_core</module>
+ の両方が httpd バイナリに静的に組み込み済みであるか、httpd.conf
+ 設定ファイルで動的にロードされるかして、httpd に組み込まれていなければ
+ なりません。これらの二つのモジュールは、設定ファイルのなかで非常に
+ 重要でウェブサーバの認証と承認で使用されるコアディレクティブと
+ その機能を提供しています。</p>
</section>
<section id="gettingitworking"><title>動作させる</title>
<p>では、サーバ上のあるディレクトリをパスワードで保護する
基本手順を示します。</p>
- <p>パスワードファイルを作る必要があります。
- このファイルは、ウェブからアクセスできる場所に
+ <p>まずはじめに、パスワードファイルを作ります。
+ どの認証プロバイダを使うかによって、パスワードファイル生成の手順は
+ 大きく異なります。ここでの例では、手始めにテキストパスワードファイルを
+ 使います。</p>
+
+ <p>このパスワードファイルは、ウェブからアクセスできる場所に
置くべきではありません。他の人がパスワードファイルを
ダウンロードできないようにするためです。例えば、
<code>/usr/local/apache/htdocs</code> でドキュメントを
@@ -117,8 +169,10 @@
<p>ファイルを作るためには、Apache 付属の <program>htpasswd</program>
を使います。このコマンドは Apache をどこにインストールしようとも、
インストールディレクトリの <code>bin</code>
- ディレクトリ以下に置かれます。ファイルを作るには、次のように
- タイプしてください。</p>
+ ディレクトリ以下に置かれます。サードバーティ製のパッケージで
+ インストールした場合は、実行パスの中で見つかるでしょう。</p>
+
+ <p>ファイルを作るには、次のようにタイプしてください。</p>
<example>
htpasswd -c /usr/local/apache/passwd/passwords rbowen
@@ -136,7 +190,7 @@
<p>もし <program>htpasswd</program> がパスの中に入っていない場合は、
もちろん、実行するためにプログラムまでのフルパスを
- タイプする必要があります。私のサーバであれば、
+ タイプする必要があります。デフォルトのインストール状態であれば、
<code>/usr/local/apache/bin/htpasswd</code>
にプログラムが置かれています。</p>
@@ -149,12 +203,14 @@
を保護したい場合は、
<code>/usr/local/apache/htdocs/secret/.htaccess</code>
か httpd.conf 中の <Directory
- /usr/local/apache/apache/htdocs/secret> セクションに
+ /usr/local/apache/htdocs/secret> セクションに
配置して、次のディレクティブを使うことができます。</p>
<example>
AuthType Basic<br />
AuthName "Restricted Files"<br />
+ # (Following line optional)<br />
+ AuthBasicProvider file<br />
AuthUserFile /usr/local/apache/passwd/passwords<br />
Require user rbowen
</example>
@@ -167,14 +223,15 @@
で実装されています。しかしながら、
これは気を付けるべき重要なポイントなのですが、
Basic 認証はクライアントからサーバへ、
- パスワードを暗号化せずに送ります。ですから、
- この方法は特に機密性の高いデータに対しては用いるべきでは
+ パスワードを暗号化せずに送ります。ですからこの方法は、
+ <module>mod_ssl</module> と組み合わせない状態では、
+ 特に機密性の高いデータに対しては用いるべきでは
ありません。 Apache ではもう一つ別の認証方法:
<code>AuthType Digest</code> をサポートしています。
この方法は <module>mod_auth_digest</module>
で実装されていて、もっと安全です。
- ごくごく最近のクライアントしか Digest
- 認証をサポートしていないようです。</p>
+ 最近のクライアントは Digest
+ 認証をサポートしているようです。</p>
<p><directive module="core">AuthName</directive>
ディレクティブでは、認証に使う <dfn>Realm</dfn> (訳注: 領域)
@@ -194,6 +251,13 @@
サーバのホスト名が変わればいつでも必ず、
クライアントは再びパスワードを尋ねる必要があります。</p>
+ <p><directive
+ module="mod_auth_basic">AuthBasicProvider</directive>
+ はデフォルト値が <code>file</code> なので、今回の場合は無くても構いません。
+ <module>mod_authn_dbm</module> や <module>mod_authn_dbd</module>
+ といった他のモジュールを使う場合には必要になります。
+ </p>
+
<p><directive module="mod_authn_file">AuthUserFile</directive>
ディレクティブは <program>htpasswd</program> で作った
パスワードファイルへのパスを設定します。
@@ -257,6 +321,8 @@
<example>
AuthType Basic<br />
AuthName "By Invitation Only"<br />
+ # Optional line:<br />
+ AuthBasicProvider file<br />
AuthUserFile /usr/local/apache/passwd/passwords<br />
AuthGroupFile /usr/local/apache/passwd/groups<br />
Require group GroupName
@@ -307,81 +373,269 @@
その時は他の認証方法を考慮に入れた方が良いでしょう。</p>
</section>
-<section id="whatotherneatstuffcanido"><title>もっと巧みに制御できない
-?</title>
- <p>ユーザ名とパスワードによる認証は認証の一つの方法に過ぎません。
- しばしば誰であるかということとは違う何かに基づいて、
- 入れるようにしたくなることもあるでしょう。
- 例えばその人がどこから来ているかといったことです。</p>
-
- <p><directive module="mod_authz_host">Allow</directive> と
- <directive module="mod_authz_host">Deny</directive>
- ディレクティブを使って、ドキュメントを要求してきたマシンの
- ホスト名やホストアドレスに基づいて許可不許可を制御できます。
- <directive module="mod_authz_host">Order</directive>
- ディレクティブはこの二つと連携して動作し、Apache
- にどの順番でフィルタを適用するかを知らせます。</p>
+<section id="dbmdbd"><title>パスワードの保存形式を変える</title>
- <p>これらのディレクティブの使い方は次のようになります。</p>
+ <p>プレーンテキストでパスワードを保存する方法には上記の問題があり、
+ データベースのような別の場所にパスワードを保存したいと思う
+ かもしれません。</p>
- <example>
- Allow from <var>address</var>
- </example>
+ <p><module>mod_authn_dbm</module> と <module>mod_authn_dbd</module>
+ を使うと、それができるようになります。
+ <directive module="mod_auth_basic">AuthBasicSource</directive>
+ で file の代わりに、<code>dbm</code> あるいは <code>dbd</code>
+ を格納形式として選べます。</p>
- <p>ここで、<var>address</var> は IP アドレス
- (または IP アドレスの一部)、あるいは完全修飾ドメイン名
- (またはドメイン名の一部) です。
- 必要であれば複数のアドレスやドメイン名を指定できます。</p>
-
- <p>例えば、もし誰かが掲示板を攻撃していて、
- その人を閉め出したいのであれば、
- 次のようにすることができます。</p>
+ <p>テキストファイルの代わりに dbm ファイルを選択する場合は、たとえば次のようにします。</p>
<example>
- Deny from 205.252.46.165
+ <Directory /www/docs/private><br />
+ AuthName "Private"<br />
+ AuthType Basic<br />
+ AuthBasicProvider dbm<br />
+ AuthDBMUserFile /www/passwords/passwd.dbm<br />
+ Require valid-user<br />
+ </Directory>
</example>
- <p>このアドレスから来る人は、このディレクティブの範囲内の
- コンテンツを見ることができないません。もし IP
- アドレスの代わりにマシン名があれば、それを使えます。</p>
+ <p>この他のオプションも存在します。詳細に関しては
+ <module>mod_authn_dbm</module> のドキュメントをご覧ください。</p>
+</section>
- <example>
- Deny from <var>host.example.com</var>
- </example>
+<section id="multprovider"><title>複数のプロバイダを使用する</title>
- <p>ドメイン全体からのアクセスを防ぎたければ、
- 単にアドレスやドメイン名の一部を指定することができます。</p>
+ <p>認証承認アーキテクチャに基づいている新しいプロバイダを使うと、
+ 認証承認の方法をひとつに縛る必要がなくなります。
+ いくつものプロバイダを組み合わせて、自分の望みの挙動にできます。
+ 次の例では file 認証プロバイダと ldap 認証プロバイダを
+ 組み合わせています。</p>
+
+ <example>
+ <Directory /www/docs/private><br />
+ AuthName "Private"<br />
+ AuthType Basic<br />
+ AuthBasicProvider file ldap<br />
+ AuthUserFile /usr/local/apache/passwd/passwords<br />
+ AuthLDAPURL ldap://ldaphost/o=yourorg<br />
+ Require valid-user
+ </example>
+
+ <p>この例では、まず file プロバイダがユーザ認証を試みます。
+ 認証できなかった場合には、ldap プロバイダが呼び出されます。
+ 組織で複数の認証格納方法を使っている際などに、
+ この方法を使って認証のスコープを拡大できます。
+ もうひとつのシナリオは、ひとつの認証タイプと異なる承認を
+ 組み合わせる方法でしょう。たとえば、パスワードファイルで認証して、
+ ldap ディレクトリで承認を行うといった場合です。</p>
+
+ <p>認証プロバイダを複数実装できるように、承認方法も複数使用できます。
+ この例では file グループ承認と ldap グループ承認を使っています。</p>
+
+ <example>
+ <Directory /www/docs/private><br />
+ AuthName "Private"<br />
+ AuthType Basic<br />
+ AuthBasicProvider file<br />
+ AuthUserFile /usr/local/apache/passwd/passwords<br />
+ AuthLDAPURL ldap://ldaphost/o=yourorg
+ AuthGroupFile /usr/local/apache/passwd/groups<br />
+ Require group GroupName<br />
+ Require ldap-group cn=mygroup,o=yourorg
+ </example>
+
+ <p>承認をより細かく制御したい場合は、
+ <directive module="mod_authz_core"><SatisfyAll></directive> と
+ <directive module="mod_authz_core"><SatisfyOne></directive>
+ ディレクティブを使って AND/OR ロジックで指定し、設定ファイルで
+ 承認の処理順番の制御ができるようになっています。
+ これらのディレクティブをどのように使えるか、網羅した例をご覧ください。</p>
- <example>
- Deny from <var>192.101.205</var><br />
- Deny from <var>cyberthugs.com</var> <var>moreidiots.com</var><br />
- Deny from ke
- </example>
+</section>
- <p><directive module="mod_authz_host">Order</directive> を使うことで、
- <directive module="mod_authz_host">Deny</directive> と
- <directive module="mod_authz_host">Allow</directive> の組み合わせで
- 入っても良いグループが本当に確実に限定できているようにできます。</p>
+<section id="beyond"><title>単純な承認のその先</title>
- <example>
- Order deny,allow<br />
- Deny from all<br />
- Allow from <var>dev.example.com</var>
- </example>
+ <p>承認の方法は、ひとつのデータソースを見て一回だけチェックするのと比べて、
+ ずっと多彩な適用方法ができます。
+ 承認処理の適用順序や制御、選択ができるようになりました。</p>
+
+ <section id="authandororder"><title>AND/OR ロジックの適用と順序付け</title>
+ <p>承認がどのような順序で適用されているか、また、それをどのように制御するかは、
+ これまで混乱を招いていました。
+ Apache 2.2 ではプロバイダベースの認証メカニズムが導入され、
+ 承認処理から認証処理とサポート機能とが切り分けられました。
+ これによるひとつの効果として、
+ 認証モジュールのロード順やモジュール自体の順序に依存することなく、
+ 指定した順番で認証プロバイダが呼び出せるよう、
+ 設定できるようになりました。
+ このプロバイダメカニズムは承認処理でも導入されています。
+ つまり、<directive module="mod_authz_core">Require</directive>
+ ディレクティブは単にどの承認手法が使われるかを指定するだけではなく、
+ それらの呼び出し順序も指定できるようになりました。
+ 複数の承認手法があるとき、その呼び出し順は、設定ファイルの
+ <directive module="mod_authz_core">Require</directive> ディレクティブ中で
+ 現れた順序と同じになります。</p>
+
+ <p>追加で導入された
+ <directive module="mod_authz_core"><SatisfyAll></directive>,
+ <directive module="mod_authz_core"><SatisfyOne></directive>
+ ディレクティブを使って、承認手法がいつ呼び出され、アクセスが許可された際に
+ どの手続きが適用されるか指定することができます。
+ たとえば、次の承認ブロックのロジックを見てみましょう:</p>
+
+ <example>
+ # if ((user == "John") ||<br />
+ # ((Group == "admin")<br />
+ # && (ldap-group <ldap-object> contains auth'ed_user)<br />
+ # && ((ldap-attribute dept == "sales")<br />
+ # || (file-group contains auth'ed_user))))<br />
+ # then<br />
+ # auth_granted<br />
+ # else<br />
+ # auth_denied<br />
+ #<br />
+ <Directory /www/mydocs><br />
+ <indent>
+ Authname ...<br />
+ AuthBasicProvider ...<br />
+ ...<br />
+ Require user John<br />
+ <SatisfyAll><br />
+ <indent>
+ Require Group admins<br />
+ Require ldap-group cn=mygroup,o=foo<br />
+ <SatisfyOne><br />
+ <indent>
+ Require ldap-attribute dept="sales"<br />
+ Require file-group<br />
+ </indent>
+ </SatisfyOne><br />
+ </indent>
+ </SatisfyAll><br />
+ </indent>
+ </Directory>
+ </example>
+
+ <p>デフォルトでは <directive module="mod_authz_core">Require</directive>
+ ディレクティブは OR 操作として扱われます。つまり、もし指定した承認手法の
+ ひとつでも合格すれば、承認されます。
+ <directive module="mod_authz_core">Require</directive> ディレクティブのセットを
+ ひとつの <directive module="mod_authz_core"><SatisfyAll></directive>
+ ブロックで囲むとAND 操作となり、全ての承認手法で合格しなければ許可されません。</p>
+
+ </section>
+
+ <section id="reqaccessctrl"><title>アクセス制御における Require と Reject の使い方</title>
+ <p>ユーザ名とパスワードによる認証は全体の一部分でしかありません。
+ 誰がアクセスしてきたかといった情報以外の条件を使いたい、
+ とよく思うことでしょう。
+ たとえば、どこからアクセスしてきているか、といった具合です。</p>
+
+ <p>承認プロバイダ <directive module="mod_authz_host">all</directive>,
+ <directive module="mod_authz_host">env</directive>,
+ <directive module="mod_authz_host">host</directive>,
+ <directive module="mod_authz_host">ip</directive>
+ を使うと、リクエストを送信してきているマシンのホスト名や IP アドレス
+ といった、ホストベースでのアクセス制御ができます。</p>
+
+ <p>これらプロバイダの扱いは
+ <directive module="mod_authz_core">Require</directive> や
+ <directive module="mod_authz_core">Reject</directive> で
+ 指定されます。これらのディレクティブは承認プロバイダを登録し、
+ リクエスト処理の承認段階で呼び出されます。たとえば:</p>
+
+ <example>
+ Require ip <var>address</var>
+ </example>
+
+ <p>ここで、<var>address</var> は IP アドレス (あるいは IP アドレスの
+ 一部) か : </p>
+
+ <example>
+ Require host <var>domain_name</var>
+ </example>
+
+ <p>ここで <var>domain_name</var> は FQDN (あるいはドメイン名の一部)
+ で、必要であれば複数のアドレスやドメイン名を書くことができます。</p>
+
+ <p>たとえば、スパムメッセージを送信してくる誰かを拒否したい場合、
+ 次のようになります : </p>
+
+ <example>
+ Reject ip 10.252.46.165
+ </example>
+
+ <p>このディレクティブが有効な範囲のコンテンツに対しては、
+ そのアドレスからアクセスしてきても見ることができません。
+ もしマシン名がわかっていて IP アドレスよりもそちらで
+ 指定したいのであれば、そのマシン名が使えます。</p>
+
+ <example>
+ Reject host <var>host.example.com</var>
+ </example>
+
+ <p>また、特定のドメインからのアクセス全てをブロックしたい場合は、
+ IP アドレスの一部や、ドメイン名が指定できます :</p>
+
+ <example>
+ <SatisfyAll><br />
+ <indent>
+ Reject ip <var>192.168.205</var><br />
+ Reject host <var>phishers.example.com</var> <var>moreidiots.example</var><br /> Reject host ke<br />
+ </indent>
+ </SatisfyAll>
+ </example>
+
+ <p><directive module="mod_authz_host">Reject</directive> ディレクティブを
+ <directive module="mod_authz_core"><SatisfyAll></directive> ブロックの中で使うと、
+ 許可したいグループにのみアクセスができるように確認できます。</p>
+
+ <p>上記の例では <directive module="mod_authz_core"><SatisfyAll></directive>
+ を使って、アクセスに合格する前段階で、全ての
+ <directive module="mod_authz_host">Reject</directive> ディレクティブが
+ 満たされていることを確認しています。</p>
+
+ </section>
+
+ <section id="filesystem"><title>アクセス制御の後方互換性</title>
+ <p>認証プロバイダベースの機構があるため、以前使用されていたディレクティブ
+ <directive module="mod_access_compat">Order</directive>,
+ <directive module="mod_access_compat">Allow</directive>,
+ <directive module="mod_access_compat">Deny</directive>,
+ <directive module="mod_access_compat">Satisfy</directive>
+ は必要なくなりました。
+ とはいうものの、古い設定ファイルでの後方互換性を提供するため、
+ これらのディレクティブは <module>mod_access_compat</module> モジュールに移されました。</p>
+
+ <p>これらのディレクティブの抱えていた問題のひとつに、承認の設定行とアクセス制御の設定行の
+ 関係がとてもあいまいだったことが挙げられます。
+ <directive module="mod_access_compat">Satisfy</directive> ディレクティブは
+ リクエスト処理中でそれ自身を呼び出すことによって、これらの 2 つの処理段階を結びつけようとします。
+ 現在は、これらのディレクティブは <module>mod_access_compat</module> に移動し、
+ 新しい認証ディレクティブと古いアクセス制御ディレクティブを混ぜて使うことは
+ 難しくなっています。この問題のため、<module>mod_authz_default</module> モジュールを
+ ロードすることがとても重要で、必須になっています。
+ <module>mod_authz_default</module> モジュールの主な目的は、どの承認プロバイダで
+ 処理されなかった承認リクエストを受けることにあります。
+ しかし、古いアクセス制御ディレクティブが用いられた場合には、
+ アクセス制御と承認を結びつけて、すべての処理段階の出力結果を見てアクセスに合格するかを決めています。
+ ですから、古いディレクティブがうまく動作しない場合は、
+ <module>mod_authz_default</module> がロードされていないからかもしれない、
+ と疑ってみてください。</p>
+
+ </section>
- <p><directive module="mod_authz_host">Allow</directive>
- ディレクティブを単純に列挙するのでは望みの動作をしないでしょう。
- なぜなら、全ての人が入れるということに加えて、
- 指定したホストからの人が入れるようにするからです。
- やりたいことは、指定した人たち<em>だけ</em>が入れるように
- することです。</p>
</section>
<section id="moreinformation"><title>追加情報</title>
<p>これら全てがどのように動作するかについて
もっと多くの情報が書かれている <module>mod_auth_basic</module> と
<module>mod_authz_host</module>
- の文書も読むとよいでしょう。</p>
+ の文書も読むとよいでしょう。
+ <directive module="mod_authn_core"><AuthnProviderAlias></directive>
+ ディレクティブを使うと、特定の認証設定が簡単に書けるようになります。</p>
+
+ <p><a href="access.html">アクセス制御</a>の方法も、
+ 関連するトピックがたくさん記載されていますので、ご覧ください。</p>
+
</section>
</manualpage>