笑うしかない。原因不明だと。

  ご提供いただきました情報を元にKaspersky社にて調査を行いましたが、お問い合わせの現象を再現することができませんでした。
  
  Kaspersky社からの回答では、過去に類似の事例があり、Kasperskyのアンチスパム機能と、お客様ご利用のメールサーバーとの組み合わせでのみ発生する環境問題となるため、問題を特定することが非常に困難な状況との事でした。

[お問い合わせの件につきましてより引用]

代理店の能力が低くて事象の本当のところを伝えられなかったのかKaspersky社が駄目駄目なのかはわからない。でもサンプルは既に提示してるし、サンプルのように作ってみればよいだけなんじゃ？少なくとも何故困難なのかメールからは判らないからこう考えちゃうな。

まぁ、いいや。もしゴニョゴニュできるようなメールが流し込めることがわかればIPAの脆弱性関連情報の届出やるだけだし。

dokuwiki のDiscussionプラグイン、有効になる場合とまったくフォームが表示されない場合と、サイトによって振る舞いが異なる場合がある。

試行錯誤した結果、どうやら導入の順序として一番最初にいれなくてはならないものらしい。

やり方としては、

1. 導入したプラグインを管理画面から全部消す
2. conf/local.php にある、消したプラグインの設定行をすべて消す。
3. Discussionプラグインを導入
4. 他のプラグインを導入

これは嵌りポイントかなぁとおもった。

本日の時点で、dokuwiki.org のプラグインページから取得できるDiscussionプラグインにはバグあり書き込みが出来ず画面が真っ白になってしまう。

これは、lib/plugins/discussion/action.php にある記述“subscription_addresslist($ID)”を“subscriber_addresslist($ID)”に直せばよい。

最新版では修正済みとの事なので、直接リポジトリから取って来てインストールするのも手です。

なんか、コロッと変わって不具合でしたー、との連絡。

対応は多分次の製品になりますーという話なのでまぁ、アンチスパムを無効にするしか避けようは無いです。

某社のＳＥさん的に、シングルサインオンってのは勝手にユーザＩＤ、パスワードを入力してログインできること、だそうです。

見た目がそれっぽければ後は(ﾟ⊿ﾟ)ｼﾗﾈ、って事ですかそうですか。

だからイントラに存在するシステムの数だけアホくせぇモジュールを作らされてます。ＷｅｂサーバのログにＩＤとパスワード残るから止めろっていってるのに強行して、そんで内部監査で指摘されて直せとか言ってくるの。やだなぁ…..

現時点では無理ですってｗ

かまだしょうゆ…？

イントラ内限定かつ１つのサーバにあるシステムに限定するのであれば、BASIC認証を使うSSOも有りであると思う。

BASIC認証と言うと反射神経的に『アカウント管理が云々』言い出されることが多いけど、BASIC認証とアカウント管理は本来別物で分離可能なわけだし。実際、Apahce httpサーバではBASIC認証のバックエンドにLDAPディレクトリを指定できます。該当のApacheにのせたアプリケーションを全部同じレルムで認証させれば同一アカウントで使えます。自分自身もこれを利用していたりします。

イメージ的には、配置するすべてのアプリケーションのレルムを同一にしておきます。最初に起動されるアプリケーションの使用前に認証が行われ、以降、他のアプリケーションも同じレルムなので認証済みとみなされる事になります(まぁ実際にはアカウント情報がクライアントから毎回送られてくる訳なのですが)

使用するアプリケーションは、このBASIC認証で指定されたアカウント情報をそっくり利用します。最近使うことが頓に多いredmineだと、

→日々是精進。: Redmineの（なんちゃって?）SSO対応

のような修正をログイン周りに忍び込ませるだけ。使い始めたdokuwikiもauth/auth.php周りに同じような修正を加えるだけですね。

BASIC認証だとアカウントが暗号化されていなくて云々、な向きにはBASIC認証の代わりにDIGEST認証を使う方法もあります。今のapacheなら使えたかと。あ、ブラウザが対応できないなら駄目ですけどね。

といいますか暗号化が必要な内部システムってSSOにしちゃまずいと思うのですけどね。