NTのApacheはスレッド化されているので、多くの競合があります。ロックがきれいなにもかかわらず粗悪な粒を有します。知らせてください、それで私は、これらの命令とモジュールを改善することができます。私は、NTのためのコード改善を受けることに特にオープンです。オペレーションユーザーにアクセス権限を与えるまでには2つの段階があります。第一段階は認証(Authentication)です,ユーザの認証情報が有効かどうかを確かめます。この段階はsearch/bind段階とも呼ばれます。認証されたユーザがリソースにアクセス可能かどうかを決定します。これはcompare段階として知られています。HTTPクライアントから渡されたユーザ名と一致するエントリーをディレクトリから検索します。ディレクトリーサーバーにbindをしようと試みます。検索してバインドするので,search/bind段階と呼ばれます。組み合わせて検索フィルターを生成します。生成されたフィルターを使ってディレクトリを検索します。検索結果が1件出なかったら、アクセスを拒否します。検索結果のエントリーから識別名(DN)を取り出します。LDAPサーバにbindします。bindが不成功ならば,アクセスを拒否します。以下のディレクティブはsearch/bind段階で使います。LDAPサーバー、検索のベースDN、検索で使う属性,拡張の検索フィルターを指定します。権限付与段階の間に、auth_ldapは、ユーザーが資源にアクセスする権利があるかを決定するように試みます。多くのこれらのチェックは、LDAPサーバーでauth_ldapに比較操作をするように要求します。これがなぜこの段階がしばしばcompare段階と呼ばれるかの理由です。ばアクセスを許しますさもなければ、アクセスを拒否しますcompare段階ではauth_ldapは以下のディレクティブを利用します。ユーザDNまたはユーザ名のどちらを利用するかを指定します。groupディレクティブ用Auth_ldapのディレクティブauth_ldapモジュールで利用するディレクティブの完全なリストです。コントロールは、下位のモジュールに単に渡されます。auth_ldapLDAPを検索するためのbindに利用するDNを指定します。bindで検索します。auth_ldapbindのDNとともに使うべきbindのパスワード。適切に保護されるべきことに注意して下さい。auth_ldapメインLDAPキャッシュの最大サイズを指定します。キャッシュには成功したsearch/bindが入っています。search/bindキャッシュを無効にするには0を設定してください。デフォルトは1024の受け取った検索です。完全な情報はauth_ldapのキャッシュの章を参照してください。auth_ldapsearch/bindキャッシュの有効時間を秒数で指定します。0はキャッシュが無効にならないという意味になります。auth_ldapauth_ldapがどのディレクトリーで証明書当局データベースを探すべきかを指定します。cert7.dbという名前のファイルの存在するディレクトリ名です。auth_ldapセットするとauth_ldapはDNを比較するためにLDAPサーバを利用します。この方法はDNを比較するための分かりやすい方法です。dnディレクティブで指定されたDNをディレクトリで検索します。この方法で偽の反対が分かりますがこちらのほうが高速です。auth_ldapキャッシュほとんどの状況でがDN比較を高速化することを気にとめてください。auth_ldapこのディレクティブはLDAP操作においていつauth_ldapがaliasesを再参照するかを指定します。デフォルトはalwaysです。auth_ldapグループのメンバーをチェックするのに利用するLDAP属性を指定します。最大10個の属性を複数述できます。設定しないとmemberとuniquemember属性を利用します。メンバー確認に利用する。offの場合,ユーザ名が利用される。o=Airiusです。Jenson,o=Airiusをmemberに持っているか調べます。offであればauth_ldapはgroupがbjensonをmemberに持っているか調べます。auth_ldapauth_ldapがLDAP比較操作で利用するキャッシュのサイズを指定します。デフォルトでは1024エントリーです。0をセットするとオペレーションキャッシュは無効になります。auth_ldapオペレーションキャッシュの有効時間を秒で指定します。デフォルトは600秒です。なければクライアントから渡されたユーザ名が入ります。デフォルトはoffです、この動作は以前のバージョンのauth_ldapの動作と同じです。LDAPサーバがTLSをサポートしている必要があります。通常のldapにはldapという文字を指定します。セキュアなLDAPにはldapsを指定します。スペースで区切って複数のサーバを記述してください。auth_ldapは接続が成功するまでそれぞれのサーバに接続を試みます。LDAPサーバが死んでしまうまで有効になります。これはラウンドロビンではないことに注意してください。全ての検索をおこなうための起点となる枝の識別名を指定します。サブツリー指定することもできます。検索に利用する属性です。どのように多くが提供されるかにかかわらず。指定しないとuidになります。これはあなたの利用するサブツリーにおいて一意の属性であるのでよいアイデアです。これはツリー上の全てのオブジェクトを検索します。フィルターは約8000文字以内に制限されています。これはどんなアプリケーションにとっても十分です。ユーザ名パスワードが結合されて以下のような検索フィルタが作成されます。権限付与段階で利用されます。userディレクティブはどのユーザ名が資源にアクセス可能か決定します。userディレクティブはどのユーザ名が資源にアクセス可能か決定します。スペースで区切って複数のユーザを1行も記述することで複数のユーザにアクセス権限を与えます。ユーザ名にスペースが含まれていれば、1行に1ユーザしか記述できません。上記の3つの行をまとめることが出来ます。groupこのディレクティブは、アクセスを許可されたメンバーのLDAPグループを指定します。LDAPグループの識別名を記述します。管理者に識別名(DN)でアクセスを与えることを可能にします。それは、アクセスを許される識別名(DN)と一致するものを指定します。dnで指定した識別名が一致したら権限が与えられます。カスタマイズ可能です。デフォルト値を使って記述を省略しました。nameをUIDの変わりに利用しています。複数のユーザーが同じcnを持っていたら問題があります。cnを検索した場合結果が1つでなくてはならないからです。ユーザは認証をUIDで行わなければなりません。LDAPのqpagerPagerID属性を持っていると仮定します。valid-user次の例は、複雑な管理上の要求をなし遂げるために、使っているフィルターの能力を説明します。フィルターなしでは、ポケベル・ユーザーと新しいLDAPグループを作って、そしてグループのメンバーが同期させられたままだということを確認する必要があったでしょう。これはフィルターでくだらなくなります。青い文字はURLで指定された属性のフィールドです。赤い文字はURLで指定されたフィルターのフィールドです。緑の文字はHTTPクライアントから受け取った情報です。Fredユーザがfuserとして接続してきたら,フィルーターは以下のようになります。(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))これは検索でfuserがポケベルを持っているときにだけ成功します。jmanagerとして接続した場合ふ、フィルターは以下です。(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))上はjmanagerがページャを持っていても持っていなくても成功します。攻撃的なキャッシュ戦略を使います。LDAPサーバーの負荷も著しく減るでしょう。2種類のLDAPキャッシュをサポートします。URLは、それ自身のこれらの3つのキャッシュのセットを持っています。ディレクトリーが大きい場合。キャッシュは成功した検索をキャッシュします。接続における無効な認証情報の比率は低いことです。無効な認証情報をキャッシュしないことでキャッシュのサイズを減らせます。パスワードはbindに使われます。bindした時間がキャッシュに保存されます。auth_ldapはキャッシュの中のパスワードと比較します。auth_ldapはsearc/bind段階を飛ばしてしまいます。2つのオペレーションキャッシュを使います。比較結果をキャッシュします。dnディレクティブの比較結果をキャッシュします。ディレクティブで制御できます。キャッシュの監視auth_ldapは管理者にキャッシュの動作を監視できるコンテントハンドラーを持ています。auth_ldapのキャッシュ情報にアクセスするのに使われます。auht_ldapのキャッシュの状態のリポートを参照できます。それぞれのhttpdインスタンスがおのおのにキャッシュを持つことになる。ベンチマークこれらのベンチマークはキャッシュの設定によるパフォーマンスの違いを比較しています。全てのベンチマークはApache1.3.4で実行しました。WWWクライアントとディレクトリサーバは全て同じです。それで、ベンチマークは、単に歴史的な理由のためにあります。最初のベンチマークは、同じページの10,000の情報検索をしました。userディレクティブを含みます。10,000回参照しています。ユーザ名は1000個の中から接続ごとにランダムに選んでいます。valid-userディレクティブを指定して保護しています。アイデアを与えているに過ぎない。実世界での条件を忠実に再現しているわけではない。TLSの利用TLSを利用するためには,AuthLDAPStartTLSをonに設定するだけです。auth_ldapは既知のCAを含んだデータベースがどこにあるのかという情報が必要となります。cert7.dbデータベースと同一です。$HOME/.netscape/cert7.dbファイルをつかむことです。mod_authモジュール)を全ての認証に用います。それらは標準のテキストによる権限付与ファイルを書き換えようとします。それで、Apache、グループメンバーを調べるためのファイル認証へをするでしょう。これはFrontPageが管理するグループが利用されることを許可します。Webへのアクセスを制限します。ディレクティブは、LDAPに関する限り妥当などんなユーザーのために成功するでしょう。これはLDAPディレクトリにエントリーがあるユーザはだれでも有効なユーザであることを意味します。ところが、FrontPageは、ローカルのユーザー・ファイルのそれらの人々だけが、妥当だと考えます。FrontPageクライアントから行えるようになります。IDは、これにとって理想です。パスワードを確認するでしょう。全体のFrontPageの許可モデルが壊れている).アパッチは、FrontPageのサポートを使うために、mod_authでコンパイルされなくてはいけません。ユーザアクセスの範囲を決定するのに利用しているからです。これがauth_ldapがAuthUserFileディレクティブをつかむことができる必要があるからです。.htaccessファイルで見つかる。それがどこで妥当なユーザーを探すべきかがリストアップすることを知っている。file.FrontPageのサポートは、まだとても実験的です。全体として、フロントページは、べとべとしたものの巨大な壊れやすい蒸気を出している山であって、そして破損と他のlossageと切り離せないです。私が明白な問題なしでそれを使っている人々を知っている間、私が何か気紛れなものをしようと試みないでしょうでその.htaccessファイル。hackに関するはるかによい方法の提案。それはhackと呼ばなくてよいぐらい十分にきれいになりました。あなたは、それを再配布して、および/またはアパッチ自身と同じ条件の下にそれを修正することができます。市場性あるいは特定の目的に対する適合性に関して、どんな保証もしません。このモジュールの著作権所有者は、モジュールの使用から生じているどんな一般の、特別な、ついでのまたは重要な被害にも対する責任を問われることができません。<dave@rudedog.org>。