16年に渡りメンテナンスをしながら使用してきたブログやWEB記事のソフトウェアを変更しました。旧ページの更新はこの投稿をもって終了し、新ページに移行しました(今表示されているページが新しいページです)。本年以降の記事は新ページに移行しておりますが、昨年以前のページはtwitter等に流したリンクがあるのでしばらくは残し、いつ消滅するかは未定です。
古い開発が終了したソフトウェアを自力で改造しながら使っていたのですが、私のプログラミング力やデザイン力が不足し色々限界を感じたので、最近流行のWordPressを試験導入してみました。するといとも簡単に今風のWEBページが作れ、しかも旧ページからの以降もほぼコピペだけと半日もかからず本当に簡単に出来てしまいました。いやはや、サンデープログラマーはもはや不要な感じですね(笑)
そんなわけでしばらくは試行錯誤が続きますが、それも楽しみとして付き合って行こうと思います。
一部混在していたURLの表記を統一したり、存在しないディレクトリへのアクセスからホームページに誘導するため、サイト内のURL転送を少し変更してみました。全て、.htaccessファイルへの記載です。
なお、何度も出てくる RewriteEngine on は、一度記載すれば以降は不要です。
URL表記の先頭のhttpとhttpsはホームページのデータのやりとりのプロトコル(定義)をさしていて、httpは暗号化されていない、httpsは暗号化されていることを意味します。最近のブラウザは必ずと言ってもいいほどhttpsに対応していて、httpだと警告を発するブラウザも増えてきました。そこで当サイトも遅ればせながらhttpsに対応して、httpへのアクセスは全てhttpsへ転送するようにしました。
.htaccess
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]普通にアクセスするにはどうでもいい事なんですが、enkai-ne.jpへのアクセスをwww.enkai-net.jpへ転送して統一するようにしました。
.htaccess
RewriteEngine On
RewriteCond %{HTTP_HOST} ^enkai-net.jp$
RewriteRule ^(.*)$ https://www.enkai-net.jp/$1 [R=301,L]ディレクトリ名を/cgi-bin/から/jq3btu/に変更したため、古いディレクトリへアクセスがあった場合のエラー回避のためディレクトリごと転送しました。
.htaccess
RewriteEngine On
RewriteRule ^cgi-bin(.*)$ /jq3btu/$1 [L,R=301]ほとんどのWEBサイトのデフォルトホームページはindex.htmlなんですが、当ブログはindex.htmlへのアクセスはフレームでbloxsom.cgiへ転送していました。これを、URL転送に変更しました。
.htaccess
RewriteEngine On
RewriteCond %{THE_REQUEST} ^.*/index.html
RewriteRule ^(.*)index.html$ https://www.enkai-net.jp/jq3btu/blosxom [L,R=301]ほとんどのWEBサイトでは、
となっており、当サイトもそのようにしていました。これを、ホームページへ転送するよう変更しました。※この設定によって、index.htmlファイルを消してしまったら上の設定は不要になります。
.htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . https://www.enkai-net.jp/jq3btu/blosxom [L]ほとんどのレンタルサーバでは以上の設定でいいのですが、自前のサーバや一部のレンタルサーバでは、index.htmlやindex.cgi等を置いてないディレクトリ名へのアクセスはディレクトリ内のファイル構造を表示してしまい、直接そのディレクトリ内のファイルが読み取れてしまいます。実はWEBサーバの初期設定がそうなっているからです。逆に言えば対策されているレンタルサーバは親切に設定変更してくれているんです。この現象を回避するため、index.htmlやindex.cgi等を置いていないディレクトリ名へのアクセスを拒否します。
.htaccess
Options -Indexes当ブログはblosxom.cgiを使わせて頂き構築しているのですが、そうするとホームページのURLが標準では～/cgi-bin/blosxom.cgiとなります。もちろんこれでも問題は無いわけですが、URLを紹介するときに長くなるしなんとなくスマートではない。っつーわけで、自室にこもる時間が長くなる時節柄、ちょっと時間を掛けて当ホームページから/cgi-bin/～.cgiを隠してみました。
WEBサーバの/cgi-bin/.htaccessに下記構文を追記して、.cgiなしのリクエストを.cgiがあるものとして処理させます。(blosxomへのリクエストがblosxom.cgiへのリクエストとして処理され、結果URLから.cgiが見えなくなる)
/cgi-bin/.htaccess
AddType application/x-httpd-cgi .cgi
MultiviewsMatch Handlers
Options +MultiViews
単純に、/cgi-bin/を/jq3btu/にrenameしました。webソース内の色々な箇所に/cgi-bin/の記載があるため、全て書き換えて完成と思ったら、blosxomのページ切り替えのプラグインpaginateが拡張子なしに対応していないようで不具合を起こしてしまいました。カテゴリ分けした表示をしてる状態でページ切り替えをする時にpaginateリンク先URLが異常となって誤動作を起こすようで、paginateの改良。これはソースを解析するのちょっと時間が掛かりました。簡単な正規表現を追加しただけですが、正規表現が苦手な私はまたここでちょっと勉強･･･
paginate
$prev_url = url(-path_info=>1,-query=>1);
$prev_url =~ s|$blosxom::url||; # 追加 拡張子なしのアクセスでの不具合対応
$prev_link = fill_template('paginate_prev_link');
：
$curr_url = url(-path_info=>1,-query=>1);
$curr_url =~ s|$blosxom::url||; # 追加 拡張子なしのアクセスでの不具合対応
：
$next_url = url(-path_info=>1,-query=>1);
$next_url =~ s|$blosxom::url||; # 追加 拡張子なしのアクセスでの不具合対応
$next_link = fill_template('paginate_next_link');ブログに「シェア」ボタンをつけたら、今度はまとめ記事にも同じように「シェア」ボタンをつけたくなって、勢いで追加しました。
YukiWikiにおいては、下記コードを追記します。
私はコメント欄の直後に「シェア」ボタンが入るよう、wiki.cgiの1230行あたり、sub embedded_to_htmlの form action=”$url_cgi” method=”post”…/formの直後に追記しました。私にとってはコメント欄の有無に連動するのが都合が良かったのですが、全てのページに入れたい方はwiki.cgiの480行あたり、sub print_footerの/divの直前あたりがいいかも知れませんね。
wiki.cgi
<!--Facebook Shere-->
<iframe src="https://www.facebook.com/plugins/share_button.php?href=$modifier_rss_link?$form{mypage}&layout=button&size=small&width=69&height=20&appId" width="69" height="20" style="border:none;overflow:hidden" scrolling="no" frameborder="0" allowTransparency="true" allow="encrypted-media"></iframe>
<!--Line Shere-->
<div class="line-it-button" data-lang="ja" data-type="like" data-url="$modifier_rss_link?$form{mypage}" data-share="true" style="display: none;"></div>
<script src="https://d.line-scdn.net/r/web/social-plugin/js/thirdparty/loader.min.js" async="async" defer="defer"></script>
<!--Twitter Shere-->
<a href="https://twitter.com/share?ref_src=twsrc%5Etfw" class="twitter-share-button" data-url="$modifier_rss_link?$form{mypage}" data-lang="ja" data-show-count="false">Tweet</a><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
ウェブサーフィンをしているとよく見かける「いいね」「シェア」のボタン。私も欲しくなってブログにつけてみました。公式サイトに詳しい方法が書かれているので簡単です。自分のサイトに下記コードを追記します。
[$url$path/$fn.html]の部分は設置したページ自身のアドレスでシェア先のアドレスですので、適宜変更下さい。blosxomにおいてはstory.htmlの$bodyの下あたりに追記します。特に変更は不要だと思いますが、細かい設定変更については公式サイトを御参照下さい。
公式サイトはコチラ→ Facebook, Line, Twitter
story.html
<!--Facebook Shere-->
<iframe src="https://www.facebook.com/plugins/share_button.php?href=$url$path/$fn.html&layout=button&size=small&width=69&height=20&appId" width="69" height="20" style="border:none;overflow:hidden" scrolling="no" frameborder="0" allowTransparency="true" allow="encrypted-media"></iframe>
<!--Line Shere-->
<div class="line-it-button" data-lang="ja" data-type="like" data-url="$url$path/$fn.html" data-share="true" style="display: none;"></div>
<script src="https://d.line-scdn.net/r/web/social-plugin/js/thirdparty/loader.min.js" async="async" defer="defer"></script>
<!--Twitter Shere-->
<a href="https://twitter.com/share?ref_src=twsrc%5Etfw" class="twitter-share-button" data-url="$url$path/$fn.html" data-lang="ja" data-show-count="false">Tweet</a><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>久々にまとめ記事を書くに当たって、やっぱりコメント欄はある方がいいのかな….ってことで、ブログとまとめ記事の両方にコメント欄を付けてみました。
元々あった機能を閉鎖していただけなので簡単簡単…っと思いきや、しばらく放置しているあいだにサーバ側で変更があったようでうまく動作せず、CGIを色々修正する羽目になりました。
コメントに限らずですが、古いフリーのCGIを改良しながら使ってるので、ちょっとやりたいことがあると全て自分でCGIを修正する必要があります。プラグインを自作したりなんやかんや、記事を書く時間よりCGIのプログラミングの時間の方が長くなっちゃって本末転倒な状態です。ってもまぁ、誰も読んでない(であろう)WEBページですから、それも趣味の範囲。楽しみながら進めております。
WEBサイトを運営して、一番ありがたいのが読者からの反応＝メールによる連絡です。当サイトも全く個人的なグループ内専用だった頃は検索ロボットを拒否して素直にメールアドレス(フリーメール)を公開していたのですが、サイトをブログ形式に変更したと同時に積極的にロボットを受け入れるようにした結果、徐々にスパムメールが来るようになりました。
そこでまず取った対策が、メールアドレスを非公開にし、よくあるメールフォームでメールを受け取る方法。でも簡単だけど、専用ソフトによる自動投稿への対策は出来ないので、WEBで管理出来るようなフリーのCGIを利用するようになりました。もちろんちょっとだけ改造して。見かけはメール投稿フォームですが、実際はBBSへの投稿になっています。すなわち、私が外出中でも、BBSに返信書き込みをすれば、返信メールを送信するようになっています(この部分が私のオリジナル改造)。
しばらくは良かったんですが、来ました！専用ソフトによる自動投稿のスパム。内容的には全く意味のない単なる悪戯？嫌がらせ？なんですが、うっとうしいことには違いない。私への技術的挑戦と受け止め、技術的に対策する事にしました。罠を仕掛けてデータ収集した結果、自動投稿ソフトは直接CGIへデータを受け渡すことがわかったため、
-IPアドレスを監視し、フォームを開いたIPアドレスと投稿したIPアドレスが異なる場合はエラーとする
-投稿IPアドレスが空欄(匿名proxy利用)の投稿はエラーとする
-フォームを開いた時間と投稿した時間を監視し、その差がやけに長いか無限大などあり得ない場合はエラーとする(自動投稿ソフトは直接CGIへデータを渡すため無限大になる)
これらの対策を施しました。よくあるIPアドレスを指定して拒否することは、簡単ですがはっきり言って全く無効です。IPアドレスの偽装は簡単ですから、相手は匿名proxyなどを使ってランダムなIPアドレスで攻めてきます。匿名proxyを使った手動投稿の多くは上の２つで回避出来ましたが、その後専用ソフトを使ったと思われる連続投稿に攻められ、３つ目の対策を行いました。これは効果てきめんで、先日までは完全にシャットアウト出来ておりました。
ところが、これを上回る投稿が出現。繰り返して書きますがCGIで書いた投稿フォームで、上記の対策をすり抜けて投稿してくる強者です。すなわち、投稿するための画面を開き、さらに数秒後にフォームにコメントを書いて投稿してくるんです（もしかしたら、本当に手作業で投稿しているのかもしれませんが）。これこそ、私への技術的挑戦！さらに、簡易的ですが対策を追加する事にしました。
-メールアドレスをチェックし、@.***形式以外はエラーとする（実は恥ずかしながら、あり得ないメールアドレスも受け付けていました）
-投稿本文が英語のみの投稿をエラーとする
これで、海外からの投稿はほぼシャットアウトされると思います。
蛇足ですが、スパム投稿対策の王道である禁止ワードチェックは、使わせて頂いているフリーのCGIが元々対応しておりました。不思議ですが、今のところ、そこに引っかかる投稿はないんですよね。コメントが数文字の、明らかに無意味な投稿が来るんです。これが、私への挑戦状と受け止めている大きな理由なんですが・・・。ホントは、数文字の投稿を無視するのが一番簡単だし、文字も決まってるからその文字を禁止ワードで拒否するのがもっと簡単なんですが。
スパム投稿対策のアルゴリズムを公開するのは手の内を明かすようでやめていたのですが、スパム投稿はほとんどが英語だから日本語で書いても読めないだろうし、黙って対策するより、同じことで困っている人がたくさんいるので、公開することにしました。罠を仕掛けてログを取れば思いつく簡単なアルゴリズムですから、隠すほどのことでもないですしね。困っているみなさん、あなたのBBSのCGIにも実装して下さい。
※ロボット検索用に書いておきます。当初の対策で拒絶出来たワードは”abc123″、それで回避出来ない強者のワードは”Hello world”。試しに前者でググってみて下さい。連続投稿され、手に負えず放置状態になっているBBSが大量に見つかる事でしょう。逆に言えば、スパム対策を行っていないBBSを淘汰するためにやってるのかな？そんなことを考えつつ上記ワードで検索してますが、まだそれらの解説ページは見つかっていません。誰も書いてない事が、私がこの記事を書く事にした理由の１つなんですが。誰か情報下さい！
WEBサイトを閲覧する際に、ブラウザの機能でデータをパソコンに保存しています。で、次に同じページを閲覧する時には表示を早くするためにそのデータを利用してインターネットからダウンロードしない仕組みになっています（ブラウザキャッシュ）。ところが、そのデータが悪さをして、掲示板など頻繁に更新されるページは、「実際には新規書き込みがあるのに表示されない」なんて不具合が生じることがあるのです。本来ならば、ブラウザがちゃんとファイルを比較して表示すべきなのですが、うまく動作しないことも多いようです。そうなると、「更新」アイコンをクリックしても更新されません。
そう言った不具合を、WEBページ側で解消するテクニックを紹介します。
htmlのヘッダ～内に次のように記述すると、そのページはキャッシュされません。
<head>
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="Expires" content="Thu, 01 Dec 1994 16:00:00 GMT">
</head>上の２行がブラウザに対しキャッシュさせないための命令、下の１行がブラウザに対しキャッシュを捨てる日付を指定する命令（過去の日付を指定することですぐに捨てさせる）です。
ブラウザのバグや機能差で必ず機能するとは限りませんが、有効な手段ではあります。
ここのところ試行錯誤しているのですが、PC関連の記事はYukiWikiを設置して移動しました。
その理由は
なことです。
取りあえず仮に２つの記事を移植しました。メニューなど面倒な部分はYukiWikiに任せられそうです。面倒がない＝書くのが楽になる＝更新頻度が少しは多くなるかも？
…4/19 19:00追記 PC関係の記事を全面的にYukiwikiに移行しました。