ファイルマネージャのファイルへのリンクがhttp://から始まるURLになっていたのですが、
公式サイトへhttpsで接続している場合にリンク先がダウンロードになる場合に少なくともFirefoxではダウンロードができないことが発覚しました。

ファイルマネージャのファイルへのリンクがhttp://から始まるURLだったのを//から始まるスキーム省略URLに変更しました。

公式テンプレートのマルチカラムレイアウトのやつはCSSのfloatを使用してマルチカラムを実現していましたが、
Google Adsenseの記事内広告を使用すると記事内でclear:bothされてその箇所移行が左サイドバーより下に落ちる感じでレイアウトが崩れてました。

floatを使わずにdisplay:table-cellを使ってなんとかなる感じなんで、管理人ブログでも使用している1-2カラム・ハイブリッドのみ変更しました。
後ほど他のテンプレートも変更予定です。

テンプレートに不具合が生じるようでしたらご報告お願いします。


[追記]
公式テンプレートの内、左サイドバー付きの2カラムレイアウトのテンプレートは同様の変更を行いましたが、
右サイドバー付きのテンプレートは記事の前に右カラムがあるため同じ方法が使えませんでした。
考えてみますが無理かも・・・

[追記2]
右サイドバー付きのテンプレートにつきましてはdisplay:flex;でほぼ対応できたのですが、
公式テンプレートの内1-2-3カラム・ハイブリッドについてはflexではfloatと同等のことができない感じでした。
ちょっとfloatを使わない方法が思いつかないので放置します。

ブログのタグ機能で、_（半角アンダーバー）から始まる2から11文字の半角英数字がタグとして設定された場合、
テンプレートのTagLoop構文でスキップするようにし、
テンプレート処理前にユーザー変数として値=1をセットするようにしました。

該当する_（アンダースコア）から始まる文字列はタグとして利用できなくなり、
代わりにテンプレート構文での条件分岐がしやすくなりました。

特定の記事が表示されるページにおいて外観を変えるようなことが簡単にできるようになりました。
具体例を上げると、「特定の記事が表示されるページは広告を表示しない。」様なことができます。

スマホでコメント入力欄がブラウザ幅を上回る場合があったので、
を公式テンプレートに追加しました。

content-box前提にフォーム部品を利用している場合は問題が生じるかもしれません。

コメントと掲示板の投稿後は元のページにリダイレクトされますが、
302 Foundでリダイレクトする際にタイムスタンプをつけてキャッシュを無効化していましたが、
302 Foundではなく303 See Otherでリダイレクトするとブラウザが更新確認をしてくれるようなので303に変更しました。

元の仕様だとタイムスタンプがURLに追加されるため、リダイレクト後に再度ページ移動をすると更新前のキャッシュが利用されてしまう場合がありましたが、
パラメータを追加しないURLにリダイレクトした上でブラウザが適切にキャッシュを更新してくれるようなので古いキャッシュが利用されることが無くなったと思われます。

Firefox,Chromium,Edgeで問題無さそうです。

www.rentafree.net の大半のコマンドはCSRF対策がされていましたが、ssl.rentafree.net はCSRF対策は行っていませんでしたのでCSRFを利用した攻撃が可能だったのですが、
ssl.rentafree.net にもCSRF対策を導入しました。

CSRF対策を導入したのは、

• パスワード変更ページからの変更要求。
• 秘密の質問設定ページからの変更要求。
• ユーザー用問い合わせフォームからの投稿。

の３箇所です。
リファラーで正規判別を行っていますので、リファラーを偽装したり送信しない場合は機能が利用できません。

パスワード変更は元々メール確認が必要でしたのでCSRFで完了させることはできませんでしたし、
他の２箇所もCSRFしても嫌がらせ程度しかできませんから重大な問題が生じる可能性はなかったと思いますが、
一応対策しておきました。

GoogleやYahoo!がSSL化してから検索文字列の取得ができなくなったのでアクセス解析の「検索文字列」の項目を削除していましたが、
どうも、bingからの流入の際にリファラから検索文字列の取得が可能な場合があるようなので、アクセス解析の「検索文字列」の項目を復活させました。

bingからの流入の際に、
bing側がhttp://の場合。（リンク先はhttp://でもhttps://でも）
リンク先がhttps://の場合。（リンク元はhttp://でもhttps://でも）
の2パターンにおいてリファラーにキーワードが含まれるようです。

というわけなので、シェアが低いですがキーワードが少し取れそうです。
bingのシェアは日本は3%程度で米国は30%程度のようです。

トラフィックエクスチェンジ対策やって、
トラフィックエクスチェンジはフレーム表示でローテーションするものと思ってたが、window.openerで制御するってことも可能か？
ってことを考えていたのですが、
window.openerを利用したフィッシングっていうものがあるらしく、うちの新着ブログのページに rel="noopener" をつけるべきだと思ったのでつけました。

新着ブログのページからユーザーブログを開く。
↓
ユーザーブログがwindow.openerを制御して偽新着ブログのページにリダイレクトする。
↓
リダイレクトに気づかなかったユーザーが偽公式サイトでパスワードを入力する。

ってことができました。
rel="noopener"をつけたので対応したブラウザだとwindow.openerの制御ができなくなりました。

トラフィックエクスチェンジの利用は禁止行為であり、フレーム解除を行う可能性があると記載しておりましたが、
ユーザーがやっているのか勝手に登録されたのかわかりませんが、トラフィックエクスチェンジ経由のリクエストを観測しました。

というわけで、クロスドメインframe（iframe）の強制解除を導入しました。
全ユーザーのブログが対象です。

フレーム表示かつクロスドメインの場合にカウントを行い、過去1日に同一ドメインからのフレーム表示が100回以上でフレームが強制解除されます。
トラフィックエクスチェンジの場合、そのサービスが停止すると思われます。


トラフィックエクスチェンジ経由でない場合も影響を受ける可能性があります。
もしフレーム表示を行う有益なサービス等がございましたらホワイトリストを導入したいと思いますので連絡してください。

Wikiのページ内に掲示板を設置する機能がありますが、
Wikiの管理ページに掲示板管理機能がなかったので削除が行なえませんでした。
Wikiの掲示板管理機能を作りました。

また、掲示板と、ブログのコメント・トラックバックの管理ページは内容をポップアップ表示するようになっていますが、
スマホ等の小さい画面で表示する際に表示位置が不適切だったので調整しました。

その際に気づいたのですが、
シングルクォートがHTMLエスケープされた'が含まれる場合に、ポップアップの際にスクリプトエラーが発生していました。
修正しました。