エントリーのカスタムフィールドでパスワードを設定する実装方法
a-blog cms では、ブログ単位で会員コンテンツとしてログインしないと見えないコンテンツを管理するような実装は標準で用意されております。しかし、今回は、もう少し簡単にエントリーのカスタムフィールドでエントリー毎の個別パスワードを設定できるような実装を考えてみます。
エントリー編集ページにカスタムJavaScriptやスタイルを適用する
エントリー編集ページは、管理ページ側と表ページ側(ダイレクト編集含む)があり、カスタムJSやCSSを適用するにはその両ページに反映する必要があります。
管理画面に設置
管理画面にJSやCSSを読み込むには、使用しているテーマフォルダ直下に admin.html を設置します。
themes/使用しているテーマ/admin.html
admin.html には下記のような記述をします。エントリー編集ページのみにカスタムJSとCSSを反映させたい場合は下記のように追記したlinkタグやscriptタグを Touch_Edit モジュールで囲います。
@extends("/_layouts/admin.html") @section("admin-css") @parent <!-- BEGIN_MODULE Touch_Edit --> <link rel="stylesheet" href="カスタムCSSのファイルパス"> <!-- END_MODULE Touch_Edit --> @endsection @section("admin-js") @parent <!-- BEGIN_MODULE Touch_Edit --> <script src="カスタムJSのファイルパス"></script> <!-- END_MODULE Touch_Edit --> @endsection
@extends
や @section
は a-blog cms の「テンプレートの継承」機能です。テンプレートの継承機能を使えるのは Ver. 2.8.0 以降になります。
表側ページに設置
表画面にJSやCSSを読み込むには、他のJSファイルやCSSファイルを読み込んでいる箇所にscriptタグやlinkタグを追加してください。
a-blog cms 標準テーマ使用の場合は下記ファイルが該当します。
themes/標準テーマ/include/head/js.html
themes/標準テーマ/include/head/link.html
js.html や link.html には下記のような追記をします。CMSに投稿者以上でログインしている時しかエントリー編集画面を表示することはないので、下記のように Touch_SessionWithContribution モジュールで囲い、投稿者以上がログインしている時しかファイル読み込みされないようにます。
例:js.html
サイト表側全体のスタイルファイル読み込みの下あたりに記述します。
<!-- BEGIN_MODULE Touch_SessionWithContribution -->
<script src="カスタムJSのファイルパス"></script>
<!-- END_MODULE Touch_SessionWithContribution -->
例:link.html
サイト表側全体のJSファイル読み込みの下あたりに記述します。
<!-- BEGIN_MODULE Touch_SessionWithContribution -->
<link rel="stylesheet" href="カスタムCSSのファイルパス">
<!-- END_MODULE Touch_SessionWithContribution -->
エントリー編集時にしか読み込みたくない場合は、エントリー編集時とダイレクト編集ONの時に読み込む必要があるため、Touch_Edit と Touch_EditInplace で囲います。
例:link.html 記述例
<!-- BEGIN_MODULE Touch_EditInplace -->
<link rel="stylesheet" href="カスタムCSSのファイルパス">
<!-- END_MODULE Touch_EditInplace -->
<!-- BEGIN_MODULE Touch_Edit -->
<link rel="stylesheet" href="カスタムCSSのファイルパス">
<!-- END_MODULE Touch_Edit -->
Ver. 3.1.17 リリースのお知らせ
この記事では、2024年6月10日にリリースした Ver. 3.1.17 及び、Ver. 3.0.36、Ver. 2.11.65 の修正内容について紹介いたします。
現在お困りの問題に該当する項目がありましたら、お早めにバージョンアップのご検討をお願いいたします。
Ver. 3.1.17 リリースノート
セキュリティ
- CMS-6828 pdfプレビュー機能のセキュリティ対応
新機能
- CMS-6808 メディア作成・更新時のHookを新しく追加(saveMedia)
- CMS-6814 エントリーの複製時にカスタムフィールド、カスタムユニット、ユニットに保存されたファイル名をランダムにするかをカスタマイズするオプション(entry_duplicate_random_filename)を config.system.yaml に追加
- CMS-6827 子ブログを含んだ初期インストールが出来る仕組みを用意
- CMS-6824 Google検索に対してサイト名を指定するWebSite構造化データを追加
- CMS-6842 インストーラーでデータベースの照合順序を選択できるように修正
変更点
- CMS-6804 CMSで作成するファイル・ディレクトリのパーミッション設定をconfig.server.phpで設定するように変更
- CMS-6840 Ajaxによる部分テンプレートアクセスにCSRFトークンによる認証を追加し、許可するtpl指定(allow_tpl_path)を個別指定しなくてもいいように改修 & Ajaxリクエストのセキュリティレベルオプションを用意(ajax_security_level)
修正点
- CMS-6803 Ver. 3.1.0 から Entry_Bodyの「前後リンク」設定をオフにしても {upperUrl} 変数(一覧リンク)が出力される問題を修正
- CMS-6810 resizeImg校正オプションでメディア画像の場合、large画像(オリジナル画像)を元にリサイズをしないように修正
- CMS-6809 メディアのlarge画像(オリジナル画像)がメディア画像修正のたびにオリジナル画像も更新されてしまい、オリジナル画像としての役割を果たせていない問題を修正
- CMS-6812 重複しないファイルパスの生成処理を修正(毎回日時情報を更新するように変更)
- CMS-6811 メディア(画像)で不要なスクエア画像が生成されている問題を修正
- CMS-6797 会員限定フラグが無効の場合、マイクロページャーが表示されない問題の修正
- CMS-6813 バージョン管理ポップアップで、バージョン作成者のユーザーが削除済みだとphpエラーが出る問題を修正
- CMS-6815 変数表のEntry_Calendarを修正
- CMS-6780 URL引用ユニットの BEGIN veil 位置を修正
- CMS-6818 バージョン編集画面で一時保存バージョンがないと、現在編集しているバージョン名が出ない問題を修正
- CMS-6782 チェックリストモジュールのコンフィグにnotFoundブロックを追加、検索がヒットしなかった場合にメッセージの表示
- CMS-6616 管理画面のサイドメニューに便利ツールのリンク集を追加
- CMS-6826 組み込みJS の「google code prettify」が post include や ダイレクト編集のようにajaxで引っ張ってきたコンテンツに発火しない問題を修正
- CMS-6823 使われていないブログのカスタムフィールド「サイト 説明」を削除
- CMS-6833 カスタムフィールドメーカー出力コードを貼り付けた時セル余白が揃いやすいよう対策
- CMS-6835 コンフィグデータが壊れている場合、コンフィグ保存しても過去のコンフィグが消えない問題を修正
- CMS-6836 アクセス設定のコンフィグページがルール毎の設定をできない問題を修正
- CMS-6838 非推奨のCSSのdevice-widthメディア特性使用箇所を削除
- CMS-6839 a-blog cmsロゴを新しいロゴに変更する
Ver. 3.0.36 リリースノート
セキュリティ
CMS-6830 pdfプレビュー機能のセキュリティ対応
修正点
- CMS-6841 画像ユニットを未来バージョンで保存すると、画像が保存できない問題を修正
Ver. 2.11.65 リリースノート
セキュリティ
- CMS-6831 pdfプレビュー機能のセキュリティ対応
主なリリースノートの詳細な内容
CMS-6814 エントリーの複製時にカスタムフィールド、カスタムユニット、ユニットに保存されたファイル名をランダムにするかをカスタマイズするオプション(entry_duplicate_random_filename)を config.system.yaml に追加
Ver. 3.1.17 より、エントリー複製時にカスタムフィールド、カスタムユニット、ユニットに保存されたファイルの名前を "元のファイル名_連番" として複製することができるようになりました。
この機能はデフォルトでは無効になっているため、config.sysrem.yaml に次の記述を追加することで有効化できます。
entry_duplicate_random_filename: 'off'
CMS-6842 インストーラーでデータベースの照合順序を選択できるように修正
インストール時に、MySQLの照合順序を選択できるようになりました。
以前のバージョンでは、データベースを提供しているサービス側で照合順序を設定する必要がありましたが、Ver. 3.1.17 より、インストール時に a-blog cms から設定できるようになります。
これにより、サーバーの管理画面からデータベースの照合順序を変更できない場合に phpMyAdmin などから照合順序を変更する必要がなくなります。
CMS-6804 CMSで作成するファイル・ディレクトリのパーミッション設定をconfig.server.phpで設定するように変更
CMSが作成するファイル・ディレクトリのパーミッションをconfig.server.phpで設定できるようになりました。
今までは、サーバーの設定によってファイル・ディレクトリ作成時のパーミッションが決定されていたため、サーバーの設定によってはCMSが作成した、ファイル・ディレクトリに意図しないパーミッションが設定されてしまう場合がありました。
そういった場合でも CMS 側の設定で、作成するファイル・ディレクトリのパーミッションを設定することができます。
デフォルトの指定だと、指定パーミッションとumaskを比較し、論理演算子のANDによって、厳しいほうのパーミッションになるようになっています。
// CMSで作成するディレクトリ・ファイルのパーミッションを設定します define('CHMOD_DIR', (0775 & ~ umask())); define('CHMOD_FILE', (0664 & ~ umask()));
例えば、CMSで作成するディレクトリのパーミッションは 775、ファイルのパーミッションは 664 にしたい場合は、config.server.php で以下のようにします。
define('CHMOD_DIR', 0775); define('CHMOD_FILE', 0664);
CMS-6840 Ajaxによる部分テンプレートアクセスにCSRFトークンによる認証を追加し、許可するtpl指定(allow_tpl_path)を個別指定しなくてもいいように改修 & Ajaxリクエストのセキュリティレベルオプションを用意(ajax_security_level)
htmx というライブラリを a-blog cms でより簡単に利用できるようにすることを目的に、URLコンテキストの tpl 指定の仕様を改善いたしました。
Ajaxによる部分テンプレートアクセスにCSRFトークンによる認証を追加し、許可するtpl指定(allow_tpl_path)を個別指定しなくてもいいように改修
ポストインクルードや htmx など、Ajax による部分テンプレートへのアクセス時に、許可するtplを private/config.system.yaml で指定(allow_tpl_path)する必要がなくなりました。
Ver. 2.11.25 より、URLコンテキストで tpl を指定する場合は private/config.sytem.yaml で指定したい tpl を設定する必要がありました。
allow_tpl_path: [inlcude/search.html, hoge/custom.html]
![]()
Ver. 2.11.25からのテンプレートの仕様変更について | お知らせ | ブログ | a-blog cms developer
a-blog cms developer
Ver. 2.11.25 で、テンプレート周りの仕様変更がありましたので、お知らせいたします。 概要 いくつかの設定(private/config.system.yaml)をデフォルトで有効にしてあります。なのでCMSの...
これは、tpl コンテキストを指定することで、同一コンテンツの複数のページが表示できてしまう問題をtpl に指定可能なパスを設定することで回避するためでしたが、Ver. 3.1.17 より Ajax によるテンプレートへのアクセスに限り、CSRFトークンによる認証でこの問題を回避するように変更されました。
これにより、ポストインクルードや htmx を利用する場合に、forbid_tpl_url_context: off
にする、tpl に指定可能なパスを allow_tpl_path
に指定するなどの準備が必要でしたが、それがなくてもポストインクルードや htmx を利用することができるようになりました。
htmx の場合は以下のような JavaScript を記述することで、htmx によるリクエストのリクエストヘッダーに CSRFトークンを付与することができます。
document.addEventListener("htmx:configRequest", function(event) { const csrfToken = document.querySelector('meta[name="csrf-token"]').content; event.detail.headers['X-CSRF-Token'] = csrfToken; });
Ajax でないアクセスで tpl コンテキストを利用する場合は、private/config.syetem.yaml でtpl に指定可能なパスを設定する必要があります。
Ajaxリクエストのセキュリティレベルオプションを用意(ajax_security_level)
互換性のため、Ajaxリクエストのセキュリティレベルは段階別に設定できるようになっています。
レベル | 説明 |
---|---|
0 | チェックを行いません。セキュリティ的に安全でないので基本的には指定しないことを推奨します。 |
1 | Referer 及び HTTPヘッダーによる Ajax 判定をチェックします。 |
2 | Referer 及び HTTPヘッダーによる Ajax 判定に加えて、CSRFトークンをチェックします。 |
private/config.system.yaml で変更することができるようになっています。
ajax_security_level: 1 # ajaxリクエストのセキュリティレベルを設定します。(0: チェックなし 1: RefererとHttpヘッダーを確認 2: CSRFトークン確認)
新規インストール時は最も厳しいセキュリティレベルである 2 となりますが、アップデート時の場合は互換性のため 1 となっております。
セキュリティレベルが 1 や 0 の場合でも Ajax によるテンプレートアクセスの場合は、private/config.system.yaml での設定は不要です。
ACMS_POST_2GET_Ajax
また、今までは ポストインクルードや htmx を利用するばあいに、ACMS_POST_2GET というモジュールを活用してURLの組み立てとリダイレクトを実装していましたが、CSRFトークンによる認証 を行うためには、新しい、ACMS_POST_2GET_Ajax というモジュールを利用する必要があります。
ACMS_POST_2GET_Ajax モジュールを利用することにより、適切にCSRFトークンによる認証が行われるだけではなく、tpl指定がある場合、tplが削除されることなるURLが組み立てられリダイレクトされます。
例えば ポストインクルードでキーワード検索を実装する場合は以下のようなコードになります。
<form action="" method="post" class="js-post_include" target="#jsChangeContents"> <input type="text" name="keyword" value="" size="15" /> <input type="hidden" name="tpl" value="include/searchResultSample.html" /> <input type="hidden" name="bid" value="%{BID}" /> <input type="submit" name="ACMS_POST_2GET_Ajax" value="検索" /> </form> <div id="jsChangeContents"> <p>この部分が置き換わります。</p> </div>
ポストインクルードや htmx などで Ajax によるテンプレート取得を行う場合は、今後 ACMS_POST_2GET_Ajax モジュールをご利用ください。
最後に
該当する問題がありましたら、お早めにバージョンアップのご検討をお願いいたします。
また、迅速にご報告いただいたユーザーの皆さま、誠にありがとうございました。
今後もご報告いただいた内容に対して真摯に受け止め修正と改善を行ってまいります。
今後ともどうぞよろしくお願いいたします。
ポストインクルードの準備・設定
Ver. 2.11.25 以降のバージョンでデフォルトで tplコンテキストの設定が無効になるような設定になりました。
理由:URLを変更すれば好きなテンプレートを簡単に指定することが出来ることにより、意図しないページが無制限にできてしまいため、セキュリティ・SEO対策としてURLコンテキストによるtpl指定は制限するようになりました。
ポストインクルードで引っ張ってくるテンプレートは、基本テンプレートを指定してインクルードするので、上記の制限によりうまくインクルードされない可能性があります。 CMSのバージョンによって対応が変わりますので、以下ご確認ください。
Ver. 3.1.16 以下 & Ver. 2.11.25 以上の場合
例えば以下のようなTPL指定をするとURLは「https://example.com/xxxx.html/tpl/include/thumbnail.html」になり、URLでtpl指定をしてしまうことになります。
<input type="hidden" name="eid" value="%{EID}" /> <input type="hidden" name="tpl" value="include/thumbnail.html" />
このままでは制限をうけて正常にインクルードできないので、以下の方法により回避します。
設定を全体を解除する(非推奨)
private/cofig.system.yaml にある forbid_tpl_url_context を off に設定します。
forbid_tpl_url_context: off
この方法は、制限をなくしてしまう設定になるので、セキュリティ・SEO的に非推奨になります。古いバージョンからのアップデートで一時的にオフにしたいなど、理由がある場合のみ指定ください。
設定を部分的に解除する
private/cofig.system.yaml にある allow_tpl_path にポストインクルードで利用するファイルを指定します。複数ある場合にはカンマで区切って設定します。
allow_tpl_path: [inlcude/search.html, hoge/custom.html]
Ver. 3.1.17 以上の場合
Ver. 3.1.17で、特に意識・設定することなく、ポストインクルードを利用できるように改善されました。
改善内容
private/config.system.yaml の「ajax_security_level」の設定に応じて、ポストインクルード(Ajax)のアクセスを認証することにより、直接のGETリクエストと、ポストインクルード(Ajax)でのリクエストを区別することが出来るようになり、tpl指定の制限をしたまま、ポストインクルード(Ajax)のリクエストは許可するということが出来るようになりました。
ajax_security_level: 2 # ajaxリクエストのセキュリティレベルを設定します。(0: チェックなし 1: RefererとHttpヘッダーを確認 2: CSRFトークン確認)
Ajaxセキュリティレベル
レベル0
ajax_security_level: 0
レベル0は、特になにも認証をしないので、基本的には設定しないでください。
レベル1
ajax_security_level: 1
レベル1は、RefererとHttpヘッダーを確認して、Ajaxリクエストであることを確認します。ポストインクルードを利用すれば自動でHTTPヘッダーは付与されるので、特に意識する必要はありません。
もしポストインクルードではなく独自のAjaxリクエストで、HTMLを取得する場合は以下HTTPヘッダーを付与ください。
Referer: https://example.com/xxxxx/xxxx.html
X-Requested-With: XMLHttpRequest
レベル2
ajax_security_level: 2
レベル2は、レベル1のチェックに加え、CSRFトークンを使った認証を行います。ポストインクルードを利用すれば自動でHTTPヘッダーにCSRFトークンが付与されるので、特に意識する必要はありません。
もしポストインクルードではなく独自のAjaxリクエストで、HTMLを取得する場合は以下HTTPヘッダーを付与ください。
Referer: https://example.com/xxxxx/xxxx.html
X-Requested-With: XMLHttpRequest
X-Csrf-Token: xxxxxxxxxxxxxxxxxxx
X-Csrf-Token に設定する値は、テンプレートに「check-csrf-token」文字列を追加することにより、CMSで追加できます。例えばクラス名で指定するなどです。
<div class="check-csrf-token">
...
</div>
CSRFトークンは、metaタグに生成されています。JavaScriptなどでこの値を取得してご利用ください。
<meta name="csrf-token" content="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">
const csrfToken = document.querySelector('meta[name="csrf-token"]').content
CSRFトークンを生成すると、セッションがスタートしてしまうので、ブラウザキャッシュなどが利用できなくなります。必要なページのみ指定するようにしてください。