無料ブログ「rentafree.net」の管理人ブログ

ブログエディターをShadow DOM化しました

ブログ記事中のHTMLタグにidを設定する際に、ブログエディターやエディターの外側に設定されているidと重複すると問題が生じる可能性がありましたので、
ブログエディターの編集中記事部分をShadow DOM化しました。

ブログエディターは複雑なんで、この変更で問題が生じないか疑わしいので、元に戻す可能性もあります。
なにか不具合に気づかれましたらご報告お願いします。

ブログエディターで<IMG>タグのloading属性を設定できるようにしました

公式JavaScriptに画像遅延ロード機能があり、機能を使うと表示領域外の画像を表示領域に入るまで読み込まないようにすることができますが、
現在ではHTML Living Standardにloading属性が追加されブラウザ機能で実現できるようになっているため、
当サービスのブログエディターでloading="lazy"を<IMG>タグに対して設定しやすくし、
「詳細設定 >領域外画像を読み込まない」をチェックして投稿した場合も記事内の<IMG>タグ全てにloading="lazy"を設定するように変更しました。

CSSでheightを設定していない状態で「詳細設定 >領域外画像を読み込まない」をチェックして投稿した場合は自動的に設定されます。
「詳細設定 >領域外画像を読み込まない」をチェックしないで投稿する場合は変換されません。
公式JavaScriptのdata-lazy属性がついた<IMG>タグのある記事を再編集する場合、記事編集画面をロードした時点でdata-lazy属性は削除されてloading="lazy"に変換されます。
公式JavaScriptの画像遅延ロード機能については当面残しますが、将来削除される可能性があります。

トップページのログインフォームをShadow DOM化しました

サービストップページにログインフォームがありますが、トップページには広告が必要なんでGoogle Adsenseが設置されています。
このような時にGoogleがログインフォームの入力内容を取得できてしまいますのでサービスにSSLを導入した際にssl.rentafree.netではGoogleを含めて外部サービスを完全に排除してSSLログイン機能を導入し、
トップページ(www.rentafree.net)の方は<iframe>を使ったサンドボックス化を検討しましたが、
検討したのが2012年で当時はFirefoxにはsandbox機能が無かったため実装できず、seamlessやframeborderなんかも混迷期だったので、これまではGoogleは信頼したうえでログインフォームを提供していましたが、
Shadow DOMという機能でログインフォームのサンドボックス化が可能なことに気づいたんで実装しました。
対応ブラウザではGoogleでもログインフォームの入力内容を取得することはできなくなりました。(ブラウザやOS自体をマルウェア化することはできるのかもしれませんがw)
SSLログイン機能(ssl.rentafree.net)の方は当初より外部サービスを排除しているので変更していません。

Firefox 63
Chrome 53
Edge 79
から機能が利用できるようです。2018年頃から可能だったみたいですね。
非対応ブラウザでも従来どおりログインフォームを使うことは可能です。

robots.txtに記載されるSitemapのschemeがhttpで固定されていました

ユーザードメインのrobots.txtにSitemapのアドレスが記載されますが、HTTPSの設定が「HTTPSが標準」か「HTTPSを強制」に設定されている場合はSitemapのURLはhttps://で始まるアドレスであるべきですが、http://から始まるアドレスで固定されていました。
「HTTPSが標準」か「HTTPSを強制」に設定されている場合はhttps://で始まるアドレスが記載されるように変更しました。

なお、
ユーザーサイトや各種Feedに関しては「HTTPSを強制」に設定されている場合にhttp://から始まるアドレスで接続しようとした場合はHTTP 301 Moved Permanentlyでリダイレクトとなり、
「HTTPSは無効」に設定されている場合にhttps://から始まるアドレスで接続しようとした場合はHTTP 404でエラーページが表示されますが、
robots.txtに関してはユーザードメインが有効な場合はhttp://でもhttps://でも表示されます。

あと、変更後にFirefoxで接続して確認しましたが、どうも対象ドメインのページがhttpsでキャッシュされている場合だと思うのですが、
http://でアドレスバーに入力して接続しようとしても自動的にhttps://のアドレスに接続してしまうみたいで確認が困難だった・・・

ファイルマネージャのリンクを変更しました

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

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

Adsenseの記事内広告を使うとレイアウトが崩れる

公式テンプレートのマルチカラムレイアウトのやつは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をセットするようにしました。

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

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

公式テンプレートのCSSを調整しました

スマホでコメント入力欄がブラウザ幅を上回る場合があったので、
fieldset{
    min-width:0px;
}
textarea,input,select{
    max-width:100%;
    box-sizing:border-box;
}
を公式テンプレートに追加しました。

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

コメントと掲示板の投稿後リダイレクトを303にしました

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

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

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

ssl.rentafree.net にCSRF対策を導入しました。

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

CSRF対策を導入したのは、
  • パスワード変更ページからの変更要求。
  • 秘密の質問設定ページからの変更要求。
  • ユーザー用問い合わせフォームからの投稿。
の3箇所です。
リファラーで正規判別を行っていますので、リファラーを偽装したり送信しない場合は機能が利用できません。

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