ポストインクルードでは通常「ACMS_POST_2GET」モジュールを利用します。

<form action="" method="post" class="js-post_include-ready">
  <input type="text" name="keyword" value="" size="15" />
  <input type="hidden" name="bid" value="%{BID}" />
  <input type="hidden" name="cid" value="%{CID}" />
  <input type="hidden" name="tpl" value="include/search.html" />
  <input type="submit" name="ACMS_POST_2GET" />
</form>

ACMS_POST_2GETモジュールは、POSTする情報（ブログ情報、エントリ情報、テンプレート、キーワードなど）から、URLに変換してリダイレクトします。ポストインクルードではこのリダイレクトされたURLのHTMLを取得して表示します。

POST_2GET_Ajax

Ver. 3.1.17 から新しいモジュール「ACMS_POST_2GET_Ajax」が利用できるようになりました。

ACMS_POST_2GETモジュールとの違い

tpl指定した場合の挙動が異なります。「ACMS_POST_2GET」モジュールの場合、tpl指定されていても、URLにtplコンテキストが入らない場合があります。

以下のポストインクルードを例に実際に取得するHTMLのURLの違いを見てみます。ここで「%{CID}」は「news」カテゴリーを指定しているものとします。

<form action="" method="post" class="js-post_include-ready">
  <input type="text" name="keyword" value="" size="15" />
  <input type="hidden" name="bid" value="%{BID}" />
  <input type="hidden" name="cid" value="%{CID}" />
  <input type="hidden" name="tpl" value="search.html" />
  <input type="submit" name="ACMS_POST_2GET" />
</form>

ACMS_POST_2GETの場合

https://example.com/news/search.html?keyword=xxxxxx

ACMS_POST_2GET_Ajaxの場合

https://example.com/news/tpl/search.html?keyword=xxxxxx

この場合「ACMS_POST_2GET」の場合は「themes/ご利用テーマ/news/search.html」テンプレートがないと404になりますが、「ACMS_POST_2GET_Ajax」の場合は、tpl指定されているので「themes/ご利用テーマ/search.html」があれば取得できることになります。

「ACMS_POST_2GET」の場合でも、テンプレートをカテゴリディレクトリに設置すれば解決しますが、多くのカテゴリがある場合は同じテンプレートをカテゴリー毎に設置しないといけなくなります。

「ACMS_POST_2GET_Ajax」であれば、必ずURLに「tplコンテキスト」が入るので、1つのテンプレートで済みます。

Ver. 3.1.17 以降のバージョンの場合、ポストインクルードで指定するモジュールは「ACMS_POST_2GET_Ajax」をご利用ください。

CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ）は、ユーザーが意図しないリクエストを第三者が送信する攻撃手法です。攻撃者は、認証されたユーザーを利用してそのユーザーの権限で悪意ある操作を行わせることを狙います。

a-blog cms を利用すればCSRF攻撃からサイトを簡単に保護できます。

CSRF攻撃の防止

a-blog cms では、CSRFトークンを使用してCSRF攻撃に対応しています。

システムによって管理されているユーザーセッションごとにCSRF「トークン」を自動的に生成します。 このトークンはユーザーのセッションに保存され、CMSが生成するHTMLにも自動的に埋め込まれるようになっております。

ユーザーが何かリクエストする際には、テンプレートに埋め込まれたCSRFトークンも一緒に送信することで、ユーザーセッションに保存されているトークンと比較し、悪意あるリクエストを排除することが出来るようになります。

以下では、CSRFトークンが使用されるリクエストや、CSRFトークンの生成方法について解説します。

CSRFトークンが必要な操作

a-blog cms で CSRFトークンが必要な操作について列挙します。

POST操作

POSTモジュールは基本的にCSRFのチェックを行いますが、例外として以下のPOSTモジュールはCSRFトークンをチェックしません。

• ACMS_POST_2GET
• ACMS_POST_2GET_Ajax
• ACMS_POST_Download
• ACMS_POST_Login_Check
• ACMS_POST_Member_SigninRedirect

Ajax（ポストインクルード）によるGETリクエスト

通常GETリクエストは、CSRFトークンをチェックしませんが、Ajaxリクエストの場合、CSRFトークンによる認証をする場合があります。

URLコンテキストで「tpl」が指定されている場合

通常以下のようなURLコンテキストにtplが入ったURLは404になり取得できません。

https://example.com/news/tpl/search.html

ただAjaxの場合は、CSRFトークンを使用して取得することが可能です。

取得HTMLが部分HTMLだった場合

通常a-blog cmsは、部分的なHTMLの取得を許可しませんが、Ajaxの場合は、CSRFトークンを使用することで部分的なHTML取得が可能になります。

ajax_security_level: 2 # ajaxリクエストのセキュリティレベルを設定します。（0: チェックなし 1: RefererとHttpヘッダーを確認 2: CSRFトークン確認）

CSRFトークンの生成条件

以下の条件の場合にユーザーセッションをスタートさせ、CSRFトークンを生成します。

• ログインしている時
• POSTリクエストの時
• 「ACMS_POST_Form_」から始まる文字列がテンプレートにある時
• 「ACMS_POST_Comment_」から始まる文字列がテンプレートにある時
• 「ACMS_POST_Shop」から始まる文字列がテンプレートにある時
• 「ACMS_POST_2GET_Ajax」から始まる文字列がテンプレートにある時
• テンプレートに「check-csrf-token」文字列がある時
• シークレットブログ・カテゴリーだった時
• ログインページなど認証系の画面の時
• phpで「IS_OTHER_LOGIN」定数が定義されている時

CSRFトークンの埋め込み場所

生成されたCSRFトークンはレスポンスされるHTMLに埋め込まれます。

form要素

HTMLのform要素内の最後に、自動でinput要素が埋め込まれます。

<form method="post">
  ...
  <input type="hidden" name="formToken" value="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">
</form>

metaタグ

HTMLのメタタグとして、head要素内に自動で埋め込まれます。

<meta name="csrf-token" content="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">

標準機能外でCSRFトークンを利用する

標準機能は、特に何もしなくてもCSRF対策がされていますが、独自にJavaScriptでリクエストを送ってレスポンスを受け取る場合などは、自身でCSRFトークンをリクエストに含める必要があります。

POSTリクエストの場合

POSTデータに以下情報を含める必要があります。

formToken: xxxxxxxxxxxxxxx

独自に開発したPOSTモジュールにJavaScriptからリクエストする例

const csrfToken = document.querySelector('meta[name="csrf-token"]').content; // メタタグからCSRFトークンを取得
const formData = new FormData();
formData.append('ACMS_POST_CustomModule', 'exec');
formData.append('formToken', csrfToken);

const response = await fetch(url, {
  method: 'POST',
  body: formData,
});

GETリクエストの場合

HTTPヘッダーに以下情報を必要があります。

Referer: https://example.com/xxxxxxx
X-Requested-With: XMLHttpRequest
X-Csrf-Token: xxxxxxxxxxxxxxxxxxx

HTMXライブラリ にCSRFトークンをセットする例

document.addEventListener("htmx:configRequest", function(event) {
  const csrfToken = document.querySelector('meta[name="csrf-token"]').content; // メタタグからCSRFトークンを取得
  event.detail.headers['X-CSRF-Token'] = csrfToken;
});

a-blog cms では、ログインセッション時間を「.env」ファイルで設定できるようになっています。
デフォルトでは、72時間有効です。

# セッション
SESSION_COOKIE_LIFETIME=259200 # セッションのCookie有効期限

ただしサーバーの環境によっては、30分程度でログアウトしてしまう現象が発生することがあります。

原因

セッション管理にはPHPのセッションの仕組みを利用しています。 このセッション情報はデフォルトですとサーバー上のファイルとして管理しているのですが、このセッションファイルの有効期限が短い可能性がございます。

PHPデフォルトの設定だと、1/100の確率で、24分より古いセッションファイルが消えるので、これが影響している可能性が高いです。

session.gc_maxlifetime

サーバに保存されているセッションファイルを保護する有効期限。

session.gc_probability / session.gc_divisor

セッションファイルが消える確率。「session.gc_probability / session.gc_divisor」の確率で削除されます。

対策

php.ini で「session.gc_maxlifetime」の期限を伸ばしていただくか、config.user.php に以下コードを設定ください。

ini_set('session.gc_maxlifetime', 259200); // 72時間を設定

このエントリーでは、Shopping Cart 拡張アプリのアップデート方法を説明します。

Shopping Cart 拡張アプリは手動でファイルを置き換えてアップデートする必要がありますので、手順を説明します。

Shopping Cart 拡張アプリをダウンロード

1. 上記のボタンからShopping Cart 拡張アプリ の zip ファイルをダウンロードしてください。
2. ダウンロードした zip ファイルを解凍し、 plugins ディレクトリから、ShoppingCart 拡張アプリを入手します。
3. 入手した ShoppingCart 拡張アプリを extension/plugins にアップロードして、ファイルの置き換えを行います。
4. ルートブログの管理画面 > 拡張アプリ から「アップデート」ボタンをクリックして、アップデートを行います。

以上で、Shopping Cart 拡張アプリのアップデートは完了です。

FTP（SFTP）ソフトなどを使用し、手動でファイルをアップロードする方法です。オンラインアップデートや手動簡単アップデートが利用できない場合にのみ、以下の方法を使用してください。

1. 最新版の a-blog cms アップデートパッケージをダウンロード

ダウンロード | a-blog cms developer より「Ver.2.x系以上からのアップデートパッケージ」をダウンロードします。 アップデートパッケージ内のファイルは、基本的にそのままサイトへアップロードし上書きすることで適用できます。

Ver. 2.x 系 からのアップデートの場合

Ver. 2.x 系のアップデートについては専用のページがあるため、Ver. 2.x 手動アップデートを参照してください。

Ver. 3.x 系 からのアップデートの場合

ダウンロードしたアップデートパッケージファイルを解凍します。アップデートに使用するのは内包されている ablogcms フォルダです。

アップデート作業中にサイト閲覧者がアクセスすると、サイトが正常に表示されない場合があります。作業時間やタイミングに注意してください。

2. アカウントやライセンスの確認

アップデート作業の前に、以下の準備を行ってください。

• CMSの管理者権限ユーザーアカウント
• ライセンスの確認：a-blog cms のマイページで現在のライセンスがアップデート後のCMSバージョンに対応しているか確認し、必要であれば license.php ファイルを取得
• FTPなどのファイルアップロード環境

3. 公式ドキュメントの確認

Release Note の確認

アップデートによる変更点をRelease Noteで確認します。詳細な変更内容を知りたい場合は、リリースノート | ブログを参照してください。

「バージョン別に気をつけること」の確認

本記事では基本的な手動アップデート方法を紹介していますが、アップデートバージョンによっては特別な注意点があるため、作業前に「バージョン別に気をつけること」を確認してください。

4. ファイル・フォルダのバックアップ

以下のファイル・フォルダをバックアップします。

• .env（カスタマイズしている場合のみ）
• .htaccess（カスタマイズしている場合のみ）
• archives
• config.server.php
• config.user.php
• cron
• extension（カスタマイズしている場合のみ）
• license.php
• media
• php/ACMS/User（カスタマイズしている場合のみ）
• php/AAPP（カスタマイズしている場合のみ）
• private（カスタマイズしている場合のみ）
• storage
• themes/カスタマイズしているテーマフォルダ
• その他カスタマイズしているフォルダ・ファイル

また、データベースのバックアップも推奨します。

5. ファイルの更新

FTPソフトなどを利用してアップデートパッケージのファイルをサイトに上書きします。 ただし、全フォルダをそのまま置き換えると必要なファイルを削除してしまう危険があるため、下記の「上書きしないフォルダ・ファイル」は削除や上書きをしないよう注意してください。
themes/system 内をカスタマイズしている場合は差分を確認しながら置き換え作業を行なってください。

上書きしないフォルダ・ファイル

• cache/.htaccess
• php/ACMS/User（カスタマイズしている場合のみ）
• php/AAPP（カスタマイズしている場合のみ）
• private/config.system.yaml
• storage
• themes/カスタマイズしているテーマフォルダ

※ 上書きしないようアップデートパッケージからあらかじめ除外されているファイルやフォルダは記載していません、（extension など）。

setup フォルダをアップロードすると、一般に公開している a-blog cms のページはメンテナンスの表示に切り替わります。

メンテナンスページ

6. データベース更新

データベースのアップデートはメンテナンスページまたは、管理画面 > 更新 ページで行います。 ここではメンテナンスページでの実行について紹介します。

6-1. メンテナンスページからのデータベース更新

下記手順でブラウザからデータベースと config.server.php をアップデートします。 アップデート時に確認事項などが画面に表示されます。各画面に書かれていることを確認しながらボタンをクリックし、アップデートを完了してください。

1. アップデート対象のサイトへブラウザでアクセス
2. メンテナンスページで管理者アカウントでログイン
3. 各画面の指示に従いアップデートを完了

6-2. setup フォルダのリネーム

アップデート完了後、FTPソフトなどを利用して setup フォルダを推測されにくい名前に変更してください。
※アップデート前の古いリネームされたsetupフォルダが残っていた場合削除して構いません。

setupフォルダが存在するまではメンテナンスページが表示されます。

7. ライセンスファイルの更新（必要な場合のみ）

a-blog cms のマイページからライセンスファイルをダウンロードした場合は、FTPソフトなどを利用して license.php を置き換えます。

8. 表示確認と公開

アップデートしたサイトへブラウザからアクセスします。
各ページの表示を確認し、問題が無ければ完了となります。 必要に応じてデバッグモードをONにしてください。

デバッグモードは、管理画面 > ユーザー > ログインしているユーザーアカウントの基本設定にある「モード」からユーザーごとにモード切り替えすることができます。デバッグモードをONにすることで、各種エラーメッセージの表示や、キャッシュ機能が無効となるなど、より動作確認に適した状態にすることができます。

ユーザーごとのデバックモード適用

サイト管理者としての操作や、ログアウトした状態での閲覧者としての表示チェックをします。
動作確認後には監査ログでエラーが出ていないか確認します。

表示や動作に問題がなければアップデートは完了です。