以下、prefs.jsとかの知識がある前提での覚え書き。
- 検索フィルタの指定を行う
単一のLDAPサーバでもフィルタ条件を変えたエントリを複数用意しておくと、便利な場合がある。例えば「全社」のデータが入っているディレクトリがある場合、フィルタ無しの全社とは別に、自分の所属する組織だけフィルタしたエントリも作っておく、的な。
LDAPサーバのプロパティの名前を変えて同じサーバを複数登録し、普通に「LDAPディレクトリサーバのプロパティ」→「詳細」→「検索フィルタ」でいちおうRFC2254っぽくフィルタを書ける。
例えば、
全社:(&(mail=*)(objectclass=*))
特定のドメインの人だけ:(&(|(mail=*\@foo\.*)(mail=*\@baz\.foo\.*))(objectclass=*))
特殊文字(@やドット)のエスケープは自分でやらないとダメ(な場合があるみたいなのでやっとくのが吉)。
また、ちょっと複雑なものを書くとクラッシュする場合もあるようなので慎重に。
- Mozilla定義のアトリビュート名と自分のLDAPがあっていない場合
昔の Netscape4.xx だと
user_pref("ldap_2.servers.myldap.attributes.cn", "氏名:cn;lang-ja,cn");
みたいに指定できたが、ThunderBird2.0 でもMozilla定義のアトリビュート名→自分のアトリビュート名の対比を指定する。
例えばMozillaで"Company"と定義されている会社名データが、自分のLDAPでは"companyname"という名前だった場合;
user_pref("ldap_2.servers.myldap.attrmap.Company", "companyname");
という定義を追加する。
ただし現在のバージョン(2.0.0.23)では言語サブタイプがついている場合には複数のアトリビュートは指定できないみたいだ(Netscapeでは可能だった)。
user_pref("ldap_2.servers.myldap.attrmap.DisplayName", "cn;lang-ja,commonname"); // これはNGだった
この場合、";lang-ja"を除くか、"cn;lang-ja"だけにすると動作する。
- 送信メール作成画面の宛先指定欄のドロップダウンリストに、例えば「会社名」とか「組織名」みたいな付加情報を付けたい
デフォルトだとDisplayName(名前)とメアドしか表示されないので、同姓同名が多い巨大ディレクトリの場合、「はてこの人どこの誰だっけ」となるのが面倒。
user_pref("mail.autoComplete.commentColumn", 2); // 1 にすると、検索しているディレクトリ名が表示されるので、2にする。
これでコメントカラムが有効になるので、そのコメントのフォーマットを、参照している自分のLDAPのアトリビュート名に変更する。LDAPのアトリビュート名は[]で括れば指定できるようである。;
user_pref("ldap_2.servers.myldap.autoComplete.commentFormat", "[divisionshortname;lang-ja]");
user_pref("ldap_2.servers.myldap.autoComplete.nameFormat", "[cn;lang-ja]");
参考になるサイト
LDAP in Mozilla ThunderbirdMail and news settingsアドレス帳の隠し設定
Proxy.pacで利用者にプロキシ設定を配っているのだが、「人によってその設定を変えたい」という話。
例えば、ユーザAでログインした場合にはA-プロキシを使わせ、ユーザBだったらB-プロキシを使わせ…というのをどうしたらいいか。
いちいちログイン画面出して…つーのはNGだし、お金もかけたくないからアリモノだけでなんとかしたい。
もちろん、マトモな方法としては グループ・ポリシーでProxy設定を行うなどの方法が正解なのはわかってるのだが、ちょっと思いついたのが、Proxy.pac自体をロードする時にユーザIDに応じて差し替えちゃえばいいんじゃね?というアイディア。
既存のProxy.pac共有サーバは、利用者と同じドメインに入っているIISなので、とりあえずはそのまんまWindows認証を流用してみることにする。
- IISに統合Windows認証ありの仮想ディレクトリ ProxyPac を作成する。
URL: http://myserver/ProxyPac/
なぜ認証ありにするかというと、WindowsのログインユーザIDをキーに処理を振り分けるため。IEとFireFoxでは統合Windows認証(NTLM)の時にはパススルー(ダイアログ無し)でログインできるので、その機能を使う。本当はちゃんとweb.configを使う方がいいんだろうが、仮想ディレクトリのプロパティで設定。利用者は同じドメインのユーザなので、このディレクトリにはアクセスできる。
- テスト用のスクリプトを用意。やることはProxy.PACファイルをMIMEタイプを付けてクライアント返すこと。
例えばこんな感じ(以下は例のための例)。ファイル名はProxyPac.aspxとする。
protected void Page_Load(object sender, EventArgs e) {
string uname;
string filename;
uname = HttpContext.Current.User.Identity.Name; // ドメイン名¥ユーザIDが返る
if ( uname == "mydomain\\userID" ) { // ¥記号はエスケープね
filename = MapPath("Special.pac"); // 特別なプロキシ設定ファイル
} else {
filename = MapPath("Normal.pac"); // 標準的なプロキシ設定ファイル
}
if(System.IO.File.Exists(filename)) {
System.IO.FileInfo fileInfo = new System.IO.FileInfo(filename);
long nSize = fileInfo.Length;
Response.Clear();
Response.ContentType = "application/x-ns-proxy-autoconfig"; // pacのMIMEタイプ
Response.WriteFile(filename, 0, nSize);
Response.End();
}
}
ここではあらかじめ用意した別ファイルの設定ファイルを読み込んで返しているが、実際にはPAC単体のデバッグが終わったらASPXの中にハードコード(コピペ)しちゃう方が速度的に有利かも。
つーか、俺的には最終的にやりたいのは人+URLなどの諸条件によってダミーのプロクシに飛ばして…みたいなことなんで、得られたIDでADを引き直して、取得した条件でJavascriptを動的に書き換えて…的なことをやっている。
- IEブラウザ側で、このサーバ(myserver)を明示的にイントラネットに属させる。
「インターネットオプション」→セキュリティ→ローカルイントラネットの「サイト」→詳細設定で、myserverを登録する。
これをやらないと、たぶんIEを立ち上げた都度、プロキシファイルを読み込むために認証ダイアログが出る。おそらく、起動したときにはプロキシ情報が読み込まれていないため、そのサーバがイントラなのかどうか判断が出来ないためだろう。
ちなみにFireFoxの場合、元々NTLMの自動ログインを有効にするためにはnetwork.automatic-ntlm-auth.trusted-urisにmyserverを登録する必要があり、その設定だけで大丈夫みたい。
- ブラウザ側で自動プロキシ設定URLを http://myserver/ProxyPac/ProxyPac.aspx に切り替えてテスト。
試したのはIE8とFireFox3.5だけ(今回のターゲットがそれしかないんで)
挙動的にはよさげだが、保守運用がめんどくさいかなぁ。
こういう仕事は基本的に受けないのだが、加藤あい似の担当者の女性の
美脚に迷ってウカウカと受けてしまったWindows SharePoint Serviceの立ち上げのお手伝い。
「インストールは終わって画面はちゃんと出るし操作もできるので、基本的な設定はできてると思うんですが検索機能が動かないんです」
「はあ」
(ううううううん
ミニスカは目の毒だなぁウレシイけど)
「よく見てみたら『イベントビューワー』に何かエラーも出てるし」
「はあ」
(なんつーかこのミニスカつーの発明した奴には
ノォベル賞をやりたいよなマジで)
と、脳内勃起していても仕方ないんでちょっとググッみると、確かにちょいと問題があるようである。
■問題:「WSS3.0で基本認証のみ有効のサイトは検索エンジンがクロールできない」 単純に言うと;
- WSSの画面でいくら検索をかけても結果が表示されない
- イベントビューワにエラーコード 2436 などが表示されている
これは
MSのサイトでも明示されているとおりの仕様ではある。このクローラは認証にフォームやBASICを使っていると使用できない。
で、どうするかなんである。
困っている美脚を放置するなんてことができるか? いやできはしないのである! 確かに上のMSのサイトには(
日本語のものは明らかに誤訳-フォーム認証の訳をそのまま引きうつしている-なので、英語版を参照のこと)手順が書いてあるが、この「手順」を読んでそのまんま理解できるやつはそう多くはなかろう。
というか、明らかに不備がある。
日本語のは論外としても英語版でさえ説明不足もいいところである。
Webを漁ると、いくつか解決策を提示しているサイトもある。例えば
CodenameさんのBlogとか
quick2seekさんのサイトとか。
だが、WSSという仕掛けはネットワーク含めた環境の設計がけっこう重要な要素で、この環境で上手くいったからそのまんま適用できるというわけでもない。美脚もこのあたりはやってみたらしいのだが上手くいかなかったと。
「うううううん。基本認証諦めるってわけにはいかないんですか? 元々イントラで使う仕掛けだし御社はちゃんとAD動いてるし」
「それがこのサーバ、運営委託していてhttpアクセスには必ずプロキシを経由しなきゃいけないんですぅ」
「…ヤリイカかぁ。こりゃあWindows認証は通らないわなぁ」
ファーム構成つーことになると話は厄介だが、幸いなことに単純なシングルサーバだ。
で、こうしてみた。
話の都合上、サーバ名(NetBios名)をfoo, DNS名をfoo.bar.co.jpとする。
- まずインストール時にWSSが勝手に作ったSharePotal-80 Webアプリケーションを削除。
別にそのまま使ってもいいのだが、美脚が弄り回した環境をいったん綺麗にしちゃいたいので(笑)
- Webアプリケーションを自前で作成しなおす。
「アプリケーション構成の管理」→「Webアプリケーションの作成または拡張」→「新しいWebアプリケーションの作成」
新しいIISWebサイトを作成する
ポート80 / ホストヘッダ指定なし
認証プロバイダ:NTLM
URL:/foo.bar.co.jp:80
検索サーバ:foo
- 「アプリケーション構成の管理」→「Webアプリケーションの作成または拡張」→「既存Webアプリケーションの拡張」で、上で作ったWebアプリケーションを拡張する。
「新しいWebサイトを作成する」:ただしこのときポートは上で使っていたのと変えてしまう。ここでは9080を指定。
ポート9080 / ホストヘッダ指定なし
認証プロバイダ:NTLM
URL:foo.bar.co.jp:9080
「領域」:イントラネット
- 「認証プロバイダ」で、
「規定」サイトが「匿名アクセスの有効化」・統合Windows認証であることを確認。
「イントラネット」を「匿名アクセスの有効化」「基本認証」をON
この状態で、IISの管理画面でディレクトリセキュリティを確認すると
foo.bar.co.jp:80 → 匿名許可・統合Windows認証
foo.bar.co.jp:9080 → 匿名許可・基本認証
になっているはず。
- iisreset。
大筋こんな感じで。
つまり、どうもmssearchは領域「規定」で定義されたサイトをクロールするようなので、そこだけNTLM認証にし(http://foo.bar.co.jp:80)、一般アクセスには同じサイトをポートを変えて見せてしまう(http://foo.bar.co.jp:9080)というセンである(今考えたらポート番号が逆の方がよかったなぁ)。
これで良しとは思わないが-「ファームにしたい」なぁとか思った瞬間に破綻する-、とりあえず検索できるようになり
美脚からソンケーの眼差しで見られたので、これでいいや(爆) で、
美脚ともう暫く過ごしたかったので、ついでに細かい問題も。
■PDF検索設定- IFilter入手&インストール。このとき合わせて17×17ドットのアイコン(pdficon_small.gif)も入手しておく。
- すでにWSSが導入済みで、Searchが動いている場合には一時停止
- MSの資料どおりレジストリの設定
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications\GUID\Gather\Search\Extensions\ExtensionList\
38
REG_SZ
pdf
を新規作成。
- 前で入手したアイコンGIF(pdficon_small.gif)を \Program Files\Common FIles\Microsoft Shared\Web Server extensions\12\TEMPLATE\IMAGES にコピーする。
- \Program Files\Common FIles\Microsoft Shared\Web Server extensions\12\TEMPLATE\XML にあるDOCICON.XMLのセクションに以下の行追加。
<Mapping Key="pdf" Value="pdficon_small.gif" OpenControl=""/>
- できればサーバ再起動(できなければsearchサービスを起動)。
ちなみにフルクロールはcmdで
stsadm -o spsearch -action fullcrawlstart
だが、この設定をやる前にすでにアップ済みのPDFがある場合には、フルクロールしても対象にならない模様。
事前登録済みのPDFファイルは削除して再登録が確実。
■XML Webパーツで「タイムアウト」が発生する 外部のニュースサイトを設定してFeedを表示させようとしたら「Webパーツがタイムアウトしました」が出る。
この話は
MSの解説にもある。
- WSSのweb.config(IISからみるとwebroot/VirtualDirectory配下のサイト個別のweb.config)をエディタで開く
- 以下のセクションを追記する
<system.net>
<defaultProxy>
<proxy proxyaddress="http://プロクシ:ポート" bypassonlocal = "true"/>
</defaultProxy>
</system.net>
- iisreset
XML Webパーツを配置して、適当なニュースサイト(
こことか)を指定して、適当なxsltを設定してやったらウマいことニュースが表示された。
「すっごーい」
「はは。いやいや。でもこれだと毎度毎度読みに行っちゃうんで、ホントはサーバ側で適当なタイミングで取得したデータを表示するだけにした方がいいと思いますよ。ちょっとしたスクリプトを作らないとだめですけど」
「…えっと、よくわからないんですけど」
あああああああああああカワイイなあ畜生しようがねぇオジサン作っちゃおうかなぁオネエちゃん綺麗だし(爆)
ここではMicrosoft Visual Web Developer 2008 Express Editionで、IISは使用せずWeb Developer 2008組み込みのWebサーバを使用するものとする。
- 本家サイトのダウンロードページから、最新のZIPファイル(本項記述時点ではFCKeditor_2.6.2.zip)とFCKeditor.Net(FCKeditor.Net_2.5.zip)をダウンロード。
- それぞれ展開する。
- デフォルトではIISに専用の仮想ディレクトリを作成するが、IISは使わないのでここではプロジェクトのWebサイトの下に配置する。
- FCKeditor_2.6.2.zipを展開したディレクトリ(FCKeditor)をまるごとプロジェクトのWebサイトの下にコピーする(_(アンダーバー)付きのファイル・ディレクトリ、使用しないスキンは省ける)。
- プロジェクトのWebサイトにbinディレクトリを作成する。
- FCKeditor.Netを展開したディレクトリの\bin\Release\2.0にあるFredCK.FCKeditorV2.dllをbinディレクトリに配置する(bin右クリック→「既存項目の追加」で展開したFredCK.FCKeditorV2.dllを指定すると、binにコピーされる)。
- FredCK.FCKeditorV2.dllを参照追加。
- 必要であれば、ツールボックスにも追加(「ツールボックス」→右クリック→「アイテムの選択」→「.NET Frameworkコンポーネント」で「参照」ボタン→FredCK.FCKeditorV2.dllを指定。ただしこれをやるならFredCK.FCKeditorV2.dllはサイト配下のbinではなく適切な共通ディレクトリの方がよかろう)
- 組み込みたいページの先頭に、
<%@ Register Assembly="FredCK.FCKeditorV2" Namespace="FredCK.FCKeditorV2" TagPrefix="FCKeditorV2" %>
を追加。 - さらにコントロールのコード
<FCKeditorV2:FCKeditor ID="FCKeditor1" runat="server" BasePath="fckeditor/" Height="400px"></FCKeditorV2:FCKeditor>
を追加(BasePathがデフォルトだと"/fckeditor/"なので、アタマの/を除外) - 念のため、fckeditor/fckeditor.jsのFCKeditor.BasePath = '/fckeditor/'のアタマの/もとっておく。
- ページをビルドして確認(BasePathの設定がおかしいとhttp 404が出る)。
プログラム中ではFCKeditor1.Valueで入力内容が参照できる。
ただしナマのデータなので、そのまま使おうとすると局面によってはASP.NETがValidateRequestで引っ掛けてHttpRequestValidationException する場合がある。開発時には@pageでValidateRequest="false"にしておくとかすると便利かも(外し忘れると大変だが)。