トップ(最新) | 次>

nDiki : cookie

cookie - クッキー

スポンサード リンク

Related term

2000年11月5日 (日)

本サイトの Referer 統計復活 このエントリーを含むはてなブックマーク

以前のサーバでは Apache で combined 形式のアクセスログをとっていて、Referer (リンク元)の統計をとっていたんだけれども、今のサーバでは Referer log が提供されていない (common 形式の提供)。

なもんで、しばらく Referer のない淋しい統計生活だったのであった。 で、今日 SSI でめでたく復活。 とりあえずちょちょっと作って実験中。 ログの出力を Apache の combined 形式と同じ形式にしたので、analog がそのまま使える(統計スクリプトの手間も省けるというもんだ)。 もっとも、combined に必要なフィールドの全ての情報が SSI では取得できない(ような)のでそこら辺は適当(適切)に埋めておいてある。

ついでに cookie による統計も実験してみようかなと思ったがサーバでは mod_usertrack が disable だった。 自前で cookie を焼くとなると、全ページを隠れCGI処理しなきゃならないので面倒だ(昔別のサーバ上でやってたけど)。 IMG でお茶を濁す方法もあるけど、なんなので cookie は見送り。

スポンサード リンク


[ 11月5日全て ]

2003年9月17日 (水)

[ WiKicker ] Last-Modified: 実装準備 このエントリーを含むはてなブックマーク

WiKicker のレスポンス改善に向けて、以前から検討していた Last-Modified: HTTP ヘッダ関連の実装を始めた。

WikiPageHTML レンダリング結果は、他の WikiPagecookie に格納された各ユーザ毎の設定に依存する。 そこで Last-Modified: の値は、

の新しい方を返す事にする。 今日は、データベースの最終更新時刻の記録/取得メソッドと、cookie への設定最終更新時刻の埋め込み機能を実装。


[ 9月17日全て ]

2003年12月21日 (日)

[ Debian ] Galeoncookie 期限 このエントリーを含むはてなブックマーク

なぜか手元の Galeonhns / wiki の cookie をそのセッション限りでしか保存してくれなくなった。

Mozilla or Firebird への乗り換えを検討。


[ 12月21日全て ]

2003年12月22日 (月)

[ Debian ] 昨日の cookie 問題は Privoxy のフィルタのせい このエントリーを含むはてなブックマーク

昨日の「Galeonがセッションを越えてcookieを保存しなくなった」問題であるが、Mozilla も同様。 で、Mozilla の Live HTTP Headers でチェックしてみると Set-Cookie: の expires がばっさり捨てられている。アレ?

で確認したら Privoxy がフィルタリングして削除していたらしい。 この間まで問題なかったのに、なんでだろ。 まいっか。

@ やっぱりGaleon

これを機会に Mozilla or Firebird に乗り換えようかと思ったが、やはりどうもしっくりこない。 Galeon の「任意のブックマークフォルダをツールバーにできて、かつ左側*1に表示できる」という機能が便利なのだが、これが他ではサポートしていないんだよね。

Mozilla の「サイドバー中のブックマーク」ではフォルダをクリックするとトグルで展開するだけなの対して、Galeon のはパーソナルツールバーのそれのようにそのままフォルダがメニューとしてポップアップしてくれる。 この機能が捨てがたい。 それから、ポップアップしたブックマークメニューですぐそこに追加できるというのも特長。 Mozilla でもこれらができれば、移行してみたいのだが。

*1あるいは任意のサイド


[ 12月22日全て ]

2003年12月23日 (火)

[ WiKicker ] 自作自演 このエントリーを含むはてなブックマーク

けいむなさんの

「若い方達の文章はとても似ていると思うのですが同一人物ということはないですよねw」

という警鐘が気になって、過去の書き込みのログをチェック。

同一PC(cookie)から、異なるユーザ名での書き込みというのがある程度確認できだのだが、

  • ユーザ名の表記ゆれ
  • 毎回違う名前にしているが、悪質ではないもの(匿名的な書き込み)
  • PCの共有(?)

というのは問題ではないと判断。 しかし1件だけ、ちょっと悪質な自作自演あり。 通常?のユーザ名と別ユーザ名を使い分け、また某アイドル名を騙ってコメント書き込んだ後にその内容に対して自身でコメントを書き込むなどをしており実際に他のユーザに誤解を与えていた。

確認できる範囲でそのユーザの書き込みを削除。 不毛な作業で疲れた。


[ 12月23日全て ]

2004年2月14日 (土)

[ WiKicker ] WikiPageHTMLレンダリング結果のキャッシュ このエントリーを含むはてなブックマーク

ようやく、HTMLレンダリング結果のキャッシュに着手。 cookie ベースでユーザ毎のカスタマイズ(名前やTZ)があるので、デフォルトのまま表示リクエストのみキャッシュが効くようにする。 キャッシュによる高速化を受けるのでは投稿してくれている常連ではなく検索エンジンから飛んできた一見さんということになるが、サーバの負荷が下がれば間接的に常連さんへのレスポンスも良くなるかと。

変換されたHTMLフラグメントをMemcachedキャッシュ。 最初、キャッシュを有効にすると逆に遅くなってしまって「まいったな」と思ったが、リクエスト処理終了毎にdisconnect_all するようにしたら、キャッシュの効果を体感できるぐらいの速度が出るようになった。


[ 2月14日全て ]

2004年6月5日 (土)

[ WiKicker ] キャッシュまわりにバグ このエントリーを含むはてなブックマーク

Memcached まわりをいじったので、キャッシュ具合をテストしていたら変な現象が。 WikiPage が表示されるべきところに、検索結果が表示されている。 あれ?

@ ページの内容が表示されるところに検索結果が

WiKicker では WikiPage のレンダリング結果も検索結果もキャッシュしているが、それぞれ別のキャッシュキーになるようにしている (WiKickerのバージョンを $V とすると、'$V:h:ページ名' と '$V:s:検索語')ので混ざるはずがないんだけれどな。 キャッシュしているデータの形式も違うし。

最初は Memcached まわりのアップデートで不具合がでたのかと思ったが、戻しても変わらない。ということは、ずっと以前からこの問題が発生していたのか。 やば。 設定でニックネームを設定している(cookie に保存している)と、その Web ブラウザに対してはキャッシュ機能が働かないようになっているので発見が遅れてしまった。

で結局コードをチェックしてみたら「WikiPage 表示と検索結果表示の View クラスを同じにしていたため、検索結果のレンダリングが WikiPage レンダリング結果と同じ領域にキャッシュされる」という風になってしまっていた。 ということで誰かがページ名で検索するとそれがキャッシュされてしまい、ページを読もうとしてもキャッシュ破棄されるまで検索結果が表示されてしまうというひどい状況になっていたと。

修正。

@ キャッシュキーのバグ

Memcached の出力をチェックしていたら、たまにエラーが起きていることを確認。 Memcachedプロトコルをチェックしたら、キーには制御文字と空白は使えないとある。 Cache::Memcached を見たらキーはそのまま through するだけ。 ということでページ名に空白が含まれている場合などの時には、まずい事になっていたようだ。 こちらは、キーを自前でエンコーディング(ページデータベースファイル名の作成に使っている base64 の亜種)するように修正。


[ 6月5日全て ]

2004年6月28日 (月)

Spybot - Search & Destroy 1.3 このエントリーを含むはてなブックマーク

rimage:http://www.naney.org/img/2004/screenshot/Spybot-2004-06-28-0001-240.png

会社の Windows BOX が重くなってきた感じ。 初めて Spybot を使ってみた。

検出されたのは cookie 系がほとんどのようだったので、spyware が直接の原因ではないのかもしれない。


[ 6月28日全て ]

2005年1月26日 (水)

DiKicker にそろそろコメント機能を実装するか このエントリーを含むはてなブックマーク

@ くっつき BBS

nDiki では、たつを氏が公開しているくっつき BBSを利用してコメント機能をつけている。 くっつき BBSは自前でBBS機能を実装しなくても、JavaScript Include を使うことでコメントをページに貼りつけられるという優れもの。

@ CGI プログラム経由の JavaScript Include 方式は遅い/負荷がかかる

nDiki では JavaScript Include する際、コメントがない(=JavaScriptファイルがない)場合でも404にならないようにCGI プログラム経由で貼りつけていた。 しかし、この方法だと1ページに多くのコメント領域があると何度もCGI プログラムが実行されるのでサーバへ負荷がかかる。

また Web ブラウザHTMLの途中でscript要素が出てくると、そのスクリプトファイルを読み込んで処理するまで残りをレンダリングできない。 このためサーバが重かったりして、途中スクリプトファイルの読み込みでひっかかるとユーザ側でのページ表示完了が遅くなってしまう。

ということでこの方式をやめて、単純にコメントJavaScriptファイルのURIを指定するようにした。 その使わなくなったCGI プログラムで、tDiaryテーマ用の「commentshortクラスdiv要素」を書き出していたので、この部分は DiKicker に戻す。 現在のコードでは、コメントが無くてもこのdiv要素が出力されてしまうので、ちょっとみぐるしいがしばらくご容赦。

@ やはりDiKickerでネイティブにコメント機能を実装しよう

コメント内の AutomaticLink 処理や cookie の連動など、前からやりたいとは思っていたのでこれを機会に実装するかな。 いろいろ決めないといかん。


[ 1月26日全て ]

2006年11月10日 (金)

WiKicker でドメイン名なしの URL でセッションがはれなかった理由 このエントリーを含むはてなブックマーク

 http://example/wiki

のように、ホスト部がドメイン名を含まないホスト名のみの URL でアクセスした場合、WiKicker では cookie ベースのセッション管理がうまく動かなかった。

cookie仕様では、cookie の domain 属性で指定できる文字列はピリオドをいくつか含まなければならないことになっている。

しかし、ホスト名だけでアクセスしたサーバへは Web ブラウザcookie を送らないというのは誤解。 domain 属性が省略されている cookie の場合は (アクセスするサーバの名前に含まれているピリオドの数が条件を満たしていなくても)ちゃんと cookie を発行したサーバへリクエストと一緒に送ってくれる。

WiKicker で何で駄目か確認したら、configuration オブジェクトの「cookie の domain 属性を決めるメソッド」で、「cookie.domain というプロパティ設定があればそれを」、「無ければ HTTP_HOST 環境変数の値を」 domain 属性で使う値として返すようになっていたから(って書いたのは昔の自分)。

次回のリリースで修正。


[ 11月10日全て ]

スポンサード リンク

■よく検索されるキーワード

perl(62) torrent(54) linux(48) 提案書(47) windows(43) 書き方(41) 使い方(29) アジェンダ(26) x31(25) 充電式カイロ(25) cvs(22) インストール(20) サンプル(20) thinkpad(19) アジェンダとは(19) f-01a(18) wiki(17) c#(16) 感想(16) カイロ(16) usb(16) java(16) 秋葉原(15) debian(15) ヨドバシカメラ(15) subversion(15) 壁紙(15) 作り方(15) 静電気(14) apache(14) グッズ(14) デロンギ(13) フリー(13) sh-01a(13) ganttproject(13) 修理(13) ssh(12) svn(12) ヨドバシ(12) truecrypt(12) ダイソー(11) 手帳(11) activeperl(11) ubuntu(11) ほぼ日手帳(11) firefox(10) mew(10) mp980(10) ドラマ(10) 日本語(10) n-01a(10) google(10) tc-1(10) 評判(10) ツール(10) djunit(9) cgi(9) 動画(9) mp3(9) オイルヒーター(9) docomo(9) rcs(9) 除去(9) centos(9) メモリ(9) エネループ(9) 設定(9) p-01a(9) tortoisesvn(9) 無印(8) ケース(8) 口コミ(8) ミノルタ(8) メール(8) インストーラ(8) 会議(8) xampp(8) 加湿器(8) af(7) 値段(7)

この日記のはてなブックマーク数 Add to Google RSS

Process Time: 15.075875s / load averages: 0.08, 0.46, 0.63
nDiki by WATANABE Yoshimasa (profile)
Powered by DiKicker
Base theme by Nana (for tDiary)