@jsakamoto

Sandcastle Oct. 2007 CTP + Sandcastle Help File Builder 1.6.0.2 で日本語ヘルプを作成

社内の自作クラスライブラリのリファレンス作成の為に、これまで Sandcastle Help File Builder（以下、SHFBと略） ver.1.3.2.0 をベースに独自に一部日本語化したカスタムバージョンを使用してきた。

しかしながら、ASp.NET AJAX や .NET 3.5 の導入などに伴い、当時の Sandcastle ではヘルプのビルドができなくなってしまった。
そこで、現時点での最新版、Sandcastle Oct. 2007 CTP + Sandcastle Help File Builder 1.6.0.2 で環境を作り直した。

さて早速 vs2005 スタイルで出力=Websiteでヘルプをビルドしてみる。
まぁ、すんなりうまくいく。
ただ、既定で用意されているスタイルシートに日本語版は無いので、英文ヘルプをベースに、自分で書いた XML ドキュメントコメントの部分だけが日本語、というヘルプになってしまう。
ITエンジニアたる者、英語にビビるようではいけないが、この英語と日本語の混在はちょっとイヤ。

ということで、生成されるヘルプの日本語化に挑戦してみる。

まず、SHFB 1.3.2.0 をカスタマイズしていた当時は（懐かしいですね）、SHFB 側に日本語訳したXMLファイルを配置することで日本語化できていたが、現在は仕組みが違うようだ。

SHFB 1.6.0.2 だと、C:\Program Files\EWSoftware\Sandcastle Help File Builder\SharedContent フォルダに ..._en-US をはじめ、各国語版の XML ファイルがあるようだが、テキストエディタで中身を開けてみるとどうにも内容が薄い。翻訳対象となりそうな英単語がぜんぜん含まれていないのだ。
とはいえ、..._ja-JP のファイル名のものは無かったので、..._en-US の同名のファイルをコピーすることで下記のファイルを上記フォルダに追加しておく。

• HanaBuilderContent_ja-JP.xml
  
• PrototypeBuilderContent_ja-JP.xml
  
• SharedBuilderContent_ja-JP.xml
  
• VS2005BuilderContent_ja-JP.xml

念のため、これら XML ファイル群をテキストエディタで編集し、英文を日本文に訳して UTF-8 で上書き保存しておく。

ここまでしておくと、SHFBを起動してのプロパティインスペクタ画面にて、Help-Langage に、"日本語(日本)" の選択肢が増えて、選択できるようになっていた。
まずは Help-Language を "日本語(日本)" に設定変更して再度ヘルプをビルド。
結果、上記邦訳の成果は無ではなかったが（"Send feedback"がちゃんと邦訳後の"フィードバックを送信"に変わっていた）、当然、まだまだほとんど英文のままである。

さてどこぞに日本語化の情報がないものか検索してみたところ、下記サイトを発見。
Sandcastle 200703 CTP 日本語化

当方、今回用意したのは、上記書き方で言うと Sandcastle 200710 CTP になるため、対象バージョンが合わない。
当方、Sandcastle 3月版でもヘルプがビルドさえできればかまわないと思っていたので 3 月版を探すもののもう見つからず。MS のサイトからは古いバージョンはダウンロードできないのだろうか。

いちかばちかで、上記ページで入手できるパッチを適用してみる。

nant を使うので、別途 nant を入手。
不慣れながら上記ページの説明に従って .build ファイルを書き替え、いざ nant 実行するも、残念ながら生成されるヘルプに何の変化も見られなかった。

バージョン違いで無理だったのか、自分のパッチ適用手順に誤りがあったのかはわからないが、原因究明はとりあえず放っておき、このパッチの内容を拝見させていただいた。

...ははぁ、なるほど、SHFB 側ではなく、Sandcastle 本体側に邦訳 XML を作るわけですか。

C:\Program Files\Sandcastle\Presentation フォルダ以下に生成するヘルプのスタイルにあわせてスタイル名のフォルダがある。
今回は取り急ぎ、自分が使う vs2005 スタイルの邦訳に注力。
上記 Presentation フォルダ以下のうち、Shared フォルダ及び vs2005 フォルダについて、各々のフォルダ以下、Contents フォルダに ja-JP フォルダを作成する。

• C:\Program Files\Sandcastle\Presentation\vs2005\Content\ja-JP
  
• C:\Program Files\Sandcastle\Presentation\Shared\content\ja-JP

で、この ja-JP フォルダに、親フォルダの XML ファイルをコピーしてくる。

ja-JP フォルダにこうしてコピーしてきた XML ファイル群をテキストエディタで開き、英文を日本文に書き替えていく。エンコード方式を UTF-8 とすることを忘れずに、邦訳後の状態で上書き保存。

これで改めてヘルプをビルドすると、ようやく日本語のヘルプが出来上がった。

2007/12/01 追記
いま改めて調べてみたら、わんくま同盟の片桐　継さんという方が、すでに 2007 Sep. CTP に対して日本語化を施されていた。2007 Oct. CTP にもそのまま適用できるかどうかわからないが、邦訳済みの XML ファイルも公開されている模様。

Ploneで統合Windows認証 (9) Plone3.0.2 + AutoUserMakerPASPlugin + mod_auth_sspi 仕上げ

前回で、Plone への統合Windfows認証によるシングルサインオンの目処が立ってきた。

いよいよ、Apache 側の設定を行って、統合 Windows 認証を実現してみる。

まず、<Apacheインストールフォルダ>/conf/httpd.conf をテキストエディタで開き、末尾に下記設定を加筆する。

<Location /hoge>
AuthType SSPI
SSPIAuth On
require valid-user
SSPIOmitDomain On
SSPIUsernameCase lower
</Location>

"AuthType SSPI" で認証方法をSSPIとし、続く "SSPIAuth On" で mod_auth_sspi の機能を有効にする。あとは "require valid-user" で匿名アクセスを不許可とすれば必ず認証が求められるようになる。

"SSPIOmitDomain" と "SSPIUsernameCase" は必須ではない。お好みで。

当方、マルチドメイン環境ではなかったこと、Windowsドメインの区切り記号である\記号がPloneでどう扱われるか心配だったことから、"SSPIOmitDomain" を On に指定して、DomainName/UserName から DomainName を除去したユーザー名を環境変数 REMOTE_USER に格納してもらうこととした。

また、ユーザー名の大文字・小文字の区別も要件として不要であったことから、いらぬ問題にぶつかることのないよう、"SSPIUsernameCase" を lower に指定して、ユーザー名は一律小文字に変換して環境変数 REMOTE_USER に格納してもらうこととした。

以上で Apache サービスを再起動し、ブラウザで http://localhost/hoge/Plone を開いてみると、成功！
Plone のログインフォームを経ることなく、現在操作中のWindowsドメインユーザー名で認証（もちろん、同時にPlone上のユーザーアカウントも自動追加）されていた。

ずいぶんと長いことかかってしまったが、こうしてようやく Plone への統合 Windows 認証によるシングルサインオンを実現することができた。

...しかしである。

喜んだのもつかの間、動作確認をしていくうちに、いくつか正常に動作しないケースが出てきた。
先に書いておくと、今回までの各種プロダクトの組み合わせや設定内容は基本的に問題なかった。追加の調整がまだ必要だったのだ。
この話題、まだもう少し続く。

つづく

Ploneで統合Windows認証 (8) Plone 3.0.2 で AutoUserMakerPASPlugin を使ってみる

前回、Plone 3.0.2 ではどうやら Remote User Folder は使えないらしいことがわかって、代替策を探すこととなった。

Google で "Plone REMOTE_USER" で検索してみると、AutoUserMakerPASPlugin という Zope プロダクトを発見。

AutoUserMakerPASPlugin
http://tid.ithaka.org/software/autousermakerpasplugin

このプロダクトも、Remote User Folder と同様に、Plone 外部の認証結果でログインし、同時にユーザーアカウントの自動追加も行う、というプロダクトらしい。もともとは統合 Windows 認証の為でなく Shibboleth というシングルサインオンの仕組みの為に作られた模様。

どうやら無償で使わせていただけるようなので、早速試してみる。
ダウンロードページから AutoUserMakerPASPlugin.zip をダウンロード。
http://tid.ithaka.org/software/autousermakerpasplugin/AutoUserMakerPASPlugin.zip/view

<Ploneインストールフォルダ>Data\Products 以下に、AutoUserMakerPASPlugin.zip を解凍してでてくる AutoUserMakerPASPlugin フォルダをまるごとコピーして Plone サービスを再起動する。

次に、Apache を経由せず直接 Zope Web サーバー経由で Plone を開き(http://localhost:8080/Plone)、管理者アカウントでログインし、[サイト設定] から [アドオンプロダクト] を開く。

すると、[インストール可能なプロダクト] として [AutoUserMakerPASPlugin 0.6] チェックボックスがあるので、これをチェックONし、[インストール]ボタンを押してインストール続行。続けてZope管理ページを開く(http://localhost:8080/manage)。

Plone/acl_users フォルダをひらくと、たしかに "AutoUserMakerPASPlugin (AutoUserMakerPAS Plugin) " の項目が増えている。これをクリックして、詳細設定を確認してみると [Options] タブの画面になる。

まず "Domain Name Stripping" という設定項目があるが、ここでいう"ドメイン"とは、user-name@domain-name 形式における domain-name を指しているそうだ。
つまり、認証されたユーザー名が "user-name@domain-name" の場合、このチェックがONならば、@以降を削除して "user-name" として取り扱うということらしい。
Apache 側、mod_auth_sspi モジュールでは dmoain-name\user-name 形式、または、domain-name\ を除いた形式のユーザー名が渡されてくる(SSPIOmitDomain {On|Off} で変わる)ので、ここの設定項目は何でもよい。既定のまま放っておく。

次に、"User Setup Headers" という設定項目について、User ID が渡されてくる環境変数の名前などを設定できるようになっている。既定では、User ID は HTTP_X_REMOTE_USER 環境変数に渡されてくるもの、と設定されているようだ。
Apache 側、mod_auth_sspi モジュールでは、REMOTE_USER 環境変数で渡してくるので、ここは REMOTE_USER に変更。

以上で [Save] ボタンを押して完了とする。

ブラウザを閉じ、あらためて http://localhost:8080/Plone を開いてみる。
ちゃんと、Plone ホームページが表示されることを確認。
続けて、Plone へのログインを試してみる（統合Windows認証ではなくて、Plone 標準のログインフォームを経由した、クッキー認証）。
無事成功。

AutoUserMakerPASPlugin はあくまでも PAS のプラグインなので、認証の選択肢が増えただけであり、既存の認証方法（例えば上記のクッキー認証）や Plone のグループ管理などには影響は与えていない模様だ。
また、ちゃんと Plone が機能しているようなので、AutoUserMakerPASPlugin のインストールは成功か、ないしは、少なくとも致命的な損害を与えるようなインストールミスは犯していないようだ（統合 Windows 認証と組み合わせていないので、インストールや設定が正しいかどうかはこの時点では判断できない）。

では残るは、Apache 側の設定とテスト。
結論を書いてしまうと、AutoUserMakerPASPlugin を使うことで、Apache + mod_auth_sspi 経由での Plone 3.0.2 への統合 Windows 認証によるシングルサインオンは成功した。
残る Apache 側の設定について詳細は後程。

つづく

ASP.NET AJAX の charCode と keyCode でハマる

ここ最近このブログに投稿しているネタは Plone 関連ばかりだが、実際には Plone ネタは現在進行形ではなく、すでに膠着した案件をおさらいと記録を兼ねて投稿している次第。
最近は、ASP.NET 開発が中心の毎日に戻っている。

さて、つい先日、ASP.NET + ASP.NET AJAX での開発でハマった出来事があった。
ASP.NET AJAX Library を利用して、とあるHTML要素の keydown イベントを取り扱う JavaScript コードを実装するタスクが発生。
keydown イベントハンドル時に、実際に押下されたキーがどのキーなのかを判別する必要があった。
今振り返れば不思議なことに、これまでキー押下イベントを扱うような Client 側 JavaScript を記述する機会がなかった（ASP.NET AJAX Libraryを使わない素の JavaScript でなら経験有り）。

さて、ASP.NET AJAX Libray のドキュメントを見てみる。
ASP.NET AJAX Library では、イベントハンドラの第一引数に、Sys.UI.DomEvent オブジェクトが渡され、この Sys.UI.DomEvent オブジェクトのフィールドなどに、そのイベントの詳細情報が格納されていてこれを参照することができるようになっている。
Sys.UI.DomEvent のリファレンスを見てみると、どうやら charCode フィールドを参照すればよいらしい。
ということで、charCode フィールドを参照する JavaScript コードを書いて走らせたのだが、なんと、charCode フィールドは undefined だというではないか。

何度もリファレンスを見直したり、コードをああでもないこうでもないとひねくり回したりして、しばらく悩んでいた。
そのうち、はたと気がついた。

keypress イベントなら charCode でいいけれど、keydown イベントなら文字じゃないキー押下も拾うはずだから、charCode という名前のフィールドはおかしんじゃないか、keyCode という名前のフィールドじゃないのか?

もういちどリファレンスを確認したが Sys.UI.DomEvent に keyCode というフィールドがあるとは明記されていないようだ。

それでも一か八かで、charCode を keyCode に書き替えて再度試してみた。
見事成功。

カーソルキーの押下を判定しているのだが、IE7のほか、IE6でもFirefox2.0.0.9でもOpera9.2でもSafari for Windows Beta1でも、ちゃんと機能した。
あとで ASP.NET AJAX Control Toolkit のソースを眺めてみたら、たしかに keyCode フィールドを参照している。

うーん、keydown イベントでは charCode フィールドではなく keyCode フィールドを参照すべしなのは常識なのだろうか?
たしかに、何らかの JavaScript ライブラリに頼らずに素の JavaScript でイベントハンドリングしていた時代は、event オブジェクトの keyCode フィールドを参照していたものだ。
しかし今回は ASP.NET AJAX Library を使うことから、ドキュメントを頼って何も考えずに charCode フィールドを参照しハマってしまった。

とりあえず一件落着だが...keyCode フィールドのことはリファレンスに明記しなくてもよいものなのだろうか、それとも明記されているのだがなにぶん英文なので読み落としているのか。
"ASP.NET AJAX charCode keyCode" で検索しても特に同じようにハマった話題は見つけることができない。
こんなことでハマったのは私だけ? 釈然としない...。

Ploneで統合Windows認証 (7) Plone 3.0.2 に RemoteUserFolder は使えない!?

さて、今度は、Plone に統合 Windows 認証に備えるべく、Remote User Folder という Zope プロダクトをインストールする。
で、結論を先に書いておくが、これはうまくいかなかった。

詳細や Zope プロダクトの入手先は割愛するが、元ネタ plone.org - Single Sign On In Windows Domains の手順に従って、Remote User Folder Zope プロダクトをインストール。

まずは Apache を通さずに、http://localhost:8080/Plone をブラウザで開いてみる。
通常どおり、Plone ホームページが表示される。
続けて「ログイン」のリンクをクリックしたところ、
「クッキー認証が無効になっていると、クッキーを使ったログインができません。」などといわれてしまった。
たしかに、もとの acl_users フォルダは削除してしまい、いまや Remote User Folder による認証しか行われなくなったので、当たり前と言えば当たり前のエラーだ。

そこで次に、Apache の側に、mod_auth_sspi モジュールによる統合Windows認証を組み込んで、ほぼ実戦の設定で試してみる（今回はこの設定についての詳細は割）。
設定変更後、今度は Apache 経由で Plone にアクセス。http://localhost/hoge/Plone をブラウザで開くと...
「残念ですが、エラーがあったようです...」とエラーになってしまった。
Apache 側の統合 Windows 認証を有効にしただけで、このようなエラーになったということは、たしかに統合 Windows 認証によるシングルサインオンが機能し始めているらしい。それにしても何のエラーになっているのか。

Plone フォルダ以下の acl_users による認証では、どうやってもログインできない状況となっているため、このままではエラーログの閲覧もままならない。
が、ルートフォルダの管理ページにHTTP認証で管理者アカウントでログインしてから（つまり、http://localhost:8080/manage をブラウザで開き、基本認証ダイアログに管理者アカウントでログイン）、Plone フォルダへ移動すれば、管理者アカウントでログインした状態で Plone 上を歩くことができる。
こうして Plone ホームページ右上の「サイト設定」から「エラーログ」を開き、エラーログを見てみると...
「エラーの種類 = AttributeError, エラーの値 = getGroups」とのこと。どうやら、ログインユーザーの所属グループを取得しようとしてエラーになってるようだ。

Remote User Folder は既存の acl_users フォルダと完全に入れ替えて使うようなのだが、たしかに Zope 管理画面から確認しても、Remote User Folder にはそもそも Plone の "グループ" という概念や機能はないようだ。
つまり、Remote User Folder は、Zope のレイヤでは利用できても、Zope 上で動作している Plone では使えない、ということなのかもしれない。

実際、現代の Plone には PAS (Pluggable Auth Service) という仕組みが備わっており、認証の仕組みをいじるには PAS 経由で機能する認証プラグインを実装せよ、というのが時代の流れらしい。

ということで Remote User Folder の利用はあきらめて、代替策を探した方がよさそうだ。
で、先に書いてしまうと、幸い、代替策は見つかった。詳細はまた後日。
とりあえず、Zope 管理ページから acl_users フォルダの差し替えを Undo し、Apache の設定変更も元に戻して、今回の作業を白紙に戻しておく。

つづく

Ploneで統合Windows認証 (6) Apache と Plone を FastCGI でつなぐ - 解決

Apache の FastCGI 経由で Plone につなぐよう構成し試してみたところ、たしかに FastCGI による接続は機能して Plone ホームページの HTML が返ってきたが、CSS スタイルシートや画像などが取ってこれないという怪現象が発生した。

あちこち検索して調べ回ったところ、こんな記事などが見つかった。どうやら、これは "accessRule.py" という、要求を受け付けたポート番号（例えば今回の事例ならば、81番が8080番か）に応じて、Zope のルートコンテンツかPloneサブフォルダのコンテンツかを振り分ける仕組みが悪さしているようだ。

ということで、http://localhost:8080/manage から Zope 管理ページにログインし、ルートにある "accessRule.py" を削除。

これで Plone サービスを再起動すると、http://localhost:81/ をブラウザで開いても、（これまでは Plone ホームページが表示されたが）Zope Quick Start ページが表示されるようになった。つまり、ポート81番でもポート8080番でもどちらのポート経由でアクセスしてもコンテンツの振り分けはされなくなった、ということだ。

これで改めて、Apache の FastCGI 経由で、http://localhost/hoge/ をブラウザで開いてみると、正しく Zope Quick Start ページが表示され、http://localhost/hoge/Plone を開けば、Plone ホームページが正しく表示された。

次はいよいよ Plone で統合 Windows 認証だ。

つづく

Ploneで統合Windows認証 (5) Apache と Plone を FastCGI でつなぐ - うまくいかない!

ではいよいよ、Apache と Plone を FastCGI でつないでみる。

まずは Plone 側の準備。
既定では、Plone 側は FastCGI インターフェースは無効になっているので、これを有効にする。
<Ploneインストールフォルダ>/etc/zope.conf をテキストエディタで開き、<fast-cgi> のエントリがコメントアウトされているので、下記のとおり書き換え。

<fast-cgi>
address localhost:82
</fast-cgi>

FastCGI インターフェースのTCPポート番号は任意なのだが、ここでは82番とした（深い意味はない）。

次に Apache 側の設定。
Apache 2.2.6 で使える FastCGI モジュールがどこから入手可能か、ちょっと迷ったが、どうやら下記が使えるらしいのでこれをダウンロード。

Apache 2.2.6 で使える mod_fastcgi
http://www.fastcgi.com/dist/mod_fastcgi-SNAP-0709231442-AP22.dll

<Apacheインストールフォルダ>/modules フォルダに、上記 mod_fastcgi-SNAP-0709231442-AP22.dll をコピー。
<Apacheインストールフォルダ>/conf/httpd.conf をテキストエディタで開き、末尾に下記を追記。

LoadModule fastcgi_module modules/mod_fastcgi-SNAP-0709231442-AP22
FastCgiExternalServer <Apacheインストールフォルダ>/htdocs/hoge -host localhost:82

ちなみに、<Apacheインストールフォルダ>/htdocs フォルダの中に、hoge フォルダが実在している必要はない。

以上で Apache・Plone の両サービスを再起動し、ブラウザから、http://localhost/hoge/ を開いてみる。すると、Apache の FastCGI 経由で Plone のホームページが表示される、と思いきや...
どういうわけか、たしかに Plone のホームページではあるものの、CSSスタイルシートや画像などが正しく取得できていないようだ。
これはどうしたものか。

つづく

Ploneで統合Windows認証 (4) Plone のインストール

次いで、Plone本体のインストールである。
Plone 3.0.2 のWindows版を下記からダウンロード。
http://plone.org/products/plone

面倒のないよう、Apache サービスは停止させた上で、上記でダウンロードしたインストーラ plone-3.0.2.exe を実行し、Plone 3.0.2 のインストールを実行。

さて、このままだと、Apache もTCPポート80番を使うし、PloneもTCPポート80番を使うので、ポート番号が衝突する。
フロントエンドには Apache を使うわけなので、Plone が使用するポート番号を変更することにする。

<Ploneインストールフォルダ>/etc フォルダに、plone.conf があるので、これをテキストエディタで開く。
ここに Plone が使用するポート番号の指定が記載されているので、次のように、ポート81番を使うように書き替えて保存しておく。

%define PLONE_WEBSERVER_PORT 81

これで Plone サービス（サービス名 = "Zope instance at ..."）を再起動。ブラウザで、http://localhost:81/ を開いてみると、無事、Plone のホームページが表示された。
さらに、http://localhost:8080/ を開くと "Zope Quck Start" ページが表示されること、
http://localhost:8080/Plone を開くと http://localhost:81/ と同じく Plone ホームページが表示されること、http://localhost:8080/manage を開くと基本認証ダイアログが開き、Plone インストール時に指定した管理者アカウントのユーザー名・パスワードを入力することで、Zope 管理ページが表示されることも確認。

つづく

Ploneで統合Windows認証 (3) Apache での統合Windows認証機能確認

さて、Apache に mod_auth_sspi モジュールを組み込んだはよいが、どうやって統合Windows認証が正しく機能していることを確認するとよいだろうか?

ここでポイントは、環境変数 REMOTE_USER に正しくアクセスもとのWindowsドメインユーザー名が格納されているかどうか、である。
元ネタ "Single Sign On In Windows Domains" にあるように、Plone に統合Windows認証でシングルサインオンするにあたり "Remote User Folder" というプロダクト（=Zope 用語でいうところの"プロダクト"） を使うのだが、これが、フロントエンドのWebサーバー（ここではApache）から渡された環境変数 REMOTE_USER に認証されたユーザー名が格納されているものとして動作するからだ。

では、どうやって環境変数 REMOTE_USER の内容を確認したらよいだろうか?

環境変数 REMOTE_USER の内容を HTML コンテンツとして送り返すような、動的なWebページを作成し、これにブラウザからアクセスすればよさそうだ。
しかし、"動的なWebページ" はどうやって作ろうか? 当初、PHP で書くことも考えた。しかし、わざわざその為だけに PHP をインストールするのもどうかとちょっと迷ってしまった。

そこで思いついたのは、SSI（Server Side Include）である。
Apache の SSI 機能を使えば、環境変数の値を、HTML ページに動的に埋め込むことが可能である。

ということで、まずはコンテンツを用意。
<Apacheインストールフォルダ>/htdocs の下に ntlmtest というサブフォルダを作成し、ここに下記内容の dump.shtml ファイルをテキストエディタで作成。

<html>
<body>
<p>REMOTE_USER = [<!--#echo var="REMOTE_USER" -->]</p>
</body>
</html>

続けて、Apache に SSI を機能させるモジュールを読み込ませる。
<Apacheインストールフォルダ>/conf/httpd.conf をテキストエディタで開き、末尾に下記を追加。

LoadModule include_module modules/mod_include.so

さらに、<Apacheインストールフォルダ>/htdocs/ntlmtest フォルダに対して、SSI 機能を有効にするために、httpd.conf 末尾に下記を追加。

<Directory "Apacheインストールフォルダ/htdocs/ntlmtest">
Options +Includes
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
</Directory>

以上で Apache サービスを再起動し、http://localhost/ntlmtest/dump.shtml をブラウザで開くと、

REMOTE_USER = [(none)]

と表示されて、たしかに SSI が機能し、dump.shtml 中の <!--#echo var="REMOTE_USER" --> の箇所が、環境変数 REMOTE_USER で置換されていることがわかる。
（この時点ではまだ認証を組み込んでいないので、環境変数 REMOTE_USER が空である為、(none) が返されている）

ここまできたらもう一息。
ntlmtest フォルダに対して、統合Windows認証による認証を指示する。先程、httpd.conf に書き加えたところへ、さらに下記を追記。

<Directory "Apacheインストールフォルダ/htdocs/ntlmtest">
Options +Includes
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
AuthType SSPI
SSPIAuth On
require valid-user
</Directory>

これで再度 Apache サービスを再起動し、http://localhost/ntlmtest/dump.shtml を開き直すと、

REMOTE_USER = [DomainName\UserName]

と無事、現在ログインしている自分の Windows ドメインユーザー名が正しく表示された。

これで、Apache を使っての統合 Windows 認証が正しく機能することが確認できたので、次のステップに進むことにする。

つづく

Ploneで統合Windows認証 (2) Apache インストール

まずは Apache のインストールから。下記からダウンロード。

Apache 2.2.6 SSL有り
http://ftp.riken.jp/net/apache/httpd/binaries/win32/apache_2.2.6-win32-x86-openssl-0.9.8e.msi

Windowsインストーラにより不自由せずインストール成功。

さて次に、Apache で統合Windows認証を受け付けるように構成してみる。
元ネタ "plone.org - Single Sign On In Windows Domains" では mod_ntlm を使え、とのことだが、http://modntlm.sourceforge.net/ を見ると、"If you're using Windows, mod_auth_sspi is what you need"、つまり、Windows 上で Apache を動かしているなら、mod_auth_sspi を使って下さい、とのこと。いろいろ検索して下記を発見、ダウンロード。

Apache 2.2.6 で使える mod_auth_sspi
http://www.gknw.net/development/apache/httpd-2.2/win32/modules/mod_auth_sspi-1.0.4-2.2.3-w32.zip

Zipファイルを解凍して、mod_auth_sspi.so を取り出したら、<Apacheインストールフォルダ>/modules フォルダにコピー。
続けて<Apacheインストールフォルダ>/conf/httpd.conf をテキストエディタで開いて、末尾に下記を追加。

LoadModule sspi_auth_module modules/mod_auth_sspi.so

とりあえずこれで httpd.conf を保存し、Apache サービスを再起動して、正しく Apache が起動してくれることまで、すなわち、httpd.conf の書き損じがなかったことを確かめる。
ちなみに、httpd.conf の書き損じがあった場合は、Apache サービスが起動しない。どこを書き間違えたのかは、Windows のイベントログにログが残されているので、これを手がかりに突き止めることができる。

さてこれで、Apacheで統合Windows認証におけるシングルサインオンを受け付ける素地ができあがった（あとは個々のフォルダやURL以下に対して統合Windows認証を求めるかどうかなどを指定していく）。
しかし、このあと、Plone との FastCGI 接続やらなにやらまだまだいろいろな配線工事が待ちかまえている。ちゃんと統合Windows認証が機能することを、この時点で、Apache 単体でたしかめておいたほうが、あとあと何かうまくいかないトラブルが発生したときに、問題の切り分けができるようになる。

ということで、統合Windows認証が機能することをたしかめたいのだが、さて、どうやってたしかめたらよいだろうか?

つづく