新規記事投稿

フォロー記事投稿

記事のキャンセル

Yasu.Fさん、ご無沙汰しております。
また、フォローをして頂き有難うございます。


9月17日に、Yasu.Fさんは書きました。

＞いちばんスマートな方法は、
＞
＞  HTTPサーバ自身の認証機構を使う
＞
＞ですね^^; これがいちばんシンプルで楽です。

そうなんですね。この点はよく分かっているつもりです。（；；）
しかし、HTTPサーバ自身の認証機構は、ディレクトリ単位で、ユーザを通過
させるか否かの二者択一しか行えませんよね。そこが問題と考えています。
実は私が実現したいのは、あるディレクトリ配下を、リードは誰でも可能、
ライトは特定者のみ可能、というような認証機能の設定です。
そのためには、cookie しかないかなって考えていた訳です。


＞具体的にどのような処理を行っているのかにもよりますが、
＞呼び出し先のCGIでパスワード文字列「そのもの」を知る必要が
＞なければ(cryptで暗号化された文字列は復号できない)、その
＞方法が使えないこともありません。
＞ただし、認証機構そのものの信頼性が半減してしまいますので
＞お薦めはしません。

実は投稿の後、自分でもいろいろ試していまして、cookie を使って何とか
解決できました。特に複雑なことをやったと言う訳ではないのですが・・・

どういう方法かと言いますと、まず、認証の有効期限はブラウザが立ち上がって
いるときのみに限定します。
それで、ブラウザ起動後、初めて投稿する（ライト）場合のみ、ユーザ名と
パスワードを入力して認証を行います。そして、次のＣＧＩで set-cookie を
を飛ばします。
以降、ブラウザ終了までは同一ユーザと認め、認証をパスするという方法
です（ただし内部的には、cookie 情報とパスワードファイルを照合する処理
は当然ながら行なっています）。

これだと、始め考えていた、INPUTタグで TYPE="HIDDEN" と指定してvalueを
ＣＧＩにおくる方法を採らなくてよく、ソースにパスワードが丸見えと言うことは
無くなります。

また、ブラウザによっては飛ばした cookie を親切にも表示してしまうものが
あります。
この点の対策としては、自前の簡単なロジックでエンコードしてから飛ばすように
してやれば一応問題は起きません(もちろんデコーダも用意します)。
# 想定ユーザ範囲には、わざわざ解読するような暇な人はいないと思う(^^;