Square の Webhook API を活用して、Square のダッシュボードから Oauth 認証を解除する

Square の Webhook API を活用することで、Square のダッシュボードから Oauth 認証を解除することができます。この記事では、Square のWebhook API と連携する手順を説明します。Webhook APIと連携することで、 Square の販売者用ダッシュボードから OAuth 認証を解除することができるようになります。

Webhook API との連携手順

Webhook API との連携は以下の手順で設定することができます。

  1. Square Developer で Webhook を登録する
  2. ShoppingCart設定に Signature Key を設定する

Square Developer で Webhook を登録する

まず、Square Developer にログインし、連携する(ご利用の) アプリケーションを選択してアプリケーションの個別ページに移動してください。次に、左のパネルから Webhooks > Subscriptions​をクリックして、Webhook subscriptions のページに移動します。Webhook subscriptions のページに移動できたら、Add subscription ボタンをクリックします。すると、Webhook の登録に必要な項目を入力するためのフォームが表示されるので入力して保存してください。

URLの入力フィールドには、https://ドメイン/bid/ブログID/webhook/shopping-cart/square/ ​を入力してください。

Events の項目は oauth.authorization.revoked の項目にチェックを付けて保存してください。また、Sandbox モードと Production モードで Webhook の設定が異なるため注意してください。


Eventsの項目で oauth.authorization.revoked の項目を選択する

Eventsの項目で oauth.authorization.revoked の項目を選択する


Webhook の登録が完了すると、Webhooks 一覧に表示されるようになります。一覧に表示された Webhook をクリックすると詳細情報が表示されるので、「Signature Key」をメモ帳などに控えておいてください。

これで、 Square Developer で Webhook を登録する作業は完了です。

ShoppingCart設定に Signature Key を設定する

次に、ShoppingCart拡張アプリに先ほど控えた「Signature Key」を設定します。ShoppingCart 設定 の決済サービスとの連携タブを表示して、Signature Key の項目に、先程控えた「Signature Key」を入力して保存してください。


ShoppingCart 拡張アプリに「Signature Key」を設定する。

ShoppingCart 拡張アプリに「Signature Key」を設定する。


これで、ShoppingCart設定に Signature Key を設定する作業は完了です。

Webhook の動作を確認する

ここまでの設定が完了したら、無事 Webhook API との連携が完了しています。実際に Webhook が正常に動作しているか確認しましょう。Square の販売者用ダッシュボードから OAuth 認証を解除したときに、ShoppingCart 拡張アプリでも OAuth 認証が解除されているかを確認します。Square の販売者用ダッシュボードから OAuth 認証を解除は、販売者用ダッシュボード > 設定 > アプリ外部ツール から行うことができます。

また、Square Developer では、Webhook API の イベントログを確認できます。イベントログから、Webhook のリクエストがうまくいっているかどうかを確認することができます。詳しくは Square Event Logs のドキュメントを参照してください。

まとめ

Webhook API を利用することで Square のダッシュボードから Oauth 認証を解除するということができるようになります。Webhook 連携をしていない場合、Square のダッシュボードから Oauth 認証を解除しても、ShoppingCart 拡張アプリでは、Oauth 認証が解除されたことにならず、よきせぬ不具合が起こる可能性がありますので、設定することをおすすめいたします。

【Square】OAuth 認証のアクセストークンを cron から自動更新する

Square との OAuth 認証で使用されているアクセストークンを cron から更新する方法を紹介します。

OAuth 認証を行う場合、APIを提供する側のサーバー(リソースサーバー)のAPIを利用するためにアクセストークンというトークンが発行されます。アクセストークンには有効期限が設定されているため、有効期限が切れる前に新しいアクセストークンを取得する必要があります。

Squareでは、7日以内ごとに OAuth のアクセストークンを自動的に更新することを推奨しています。7日以内に更新することで、エラーを発見し解決するための十分な時間を確保できます。アクセストークンの更新を行わない場合、アクセストークンの更新の失敗を見逃し、Webサイトの運用者やその顧客に予期せぬ経験をもたらすリスクが高くなります。


ShoppingCart 拡張アプリでは、インストール時から標準で用意されている a-blog cms をスタンドーアローン起動できるプログラムを利用して、cron から OAuth 認証のアクセストークンを定期的に自動更新することができます。

a-blog cms インストールした時点で、cron/example.php に a-blog cms をスタンドーアローン起動できるプログラムを利用するためのサンプルファイルが用意されています。この記事ではこの cron/example.php を利用することを前提として説明します。

cron/example.php を以下のように記述します。

<?php

// デフォルトではBID=1の文脈で実行されるため、
// OAuth認証を行っているブログのBIDが1以外の場合、
// php/standalone.php を読み込むより前にBIDを設定してください。
define('BID', 2);

// 設置場所に合わせて、php/standalone のパスを合わせてください。
require_once dirname(__FILE__) . '/../php/standalone.php';

use Acms\Plugins\ShoppingCart\ServiceProvider;

set_time_limit(0);
ini_set('memory_limit', '512M');

acmsStandAloneRun(function () {
    acmsStdMessage('[Start] 処理を開始しました');
    try {
        // ShoppingCart拡張アプリを初期化
        $App = new ServiceProvider();
        $App->init();

        App::make('square.service.oauth');

        acmsStdMessage('[Success] 処理を完了しました');
    } catch (\Exception $e) {
        acmsStdMessage('[Error] ' . $e->getMessage());
        return false;
    }
    return true;
});

実行時にアクセストークンの更新が必要かどうかを判定し、必要であればアクセストークンの更新を行います。

次に、サーバーでcronの設定を行います。7日おきに実行されるように設定したいため、例えば以下のように設定します。

0 0 */7 * * php path/to/cron/example.php

これで7日おきに、cronが実行され、アクセストークンの更新が必要かどうかを判定し、必要であればアクセストークンの更新を自動で行う事ができるようになります。

エントリー保存時や設定変更時に固まってしまう(Ver. 2系)

* この内容は Ver. 3系では、この機能自体廃止されているので発生しません。

サーバーの構成変更時などに、エントリー保存や設定変更などPOST操作を行うと固まってしまい、タイムアウトエラーが出る時があります。

この場合、ダッシュボードから設定できる「キャッシュ生成リスト」が設定されていないかご確認をお願いします。 この機能は、POST時に自動的にキャッシュを生成するようにHTTPリクエストが飛ぶようになっているのですが、 サーバーの変更でこの機能が動作しなくなってタイムアウトしている可能性が考えられます。


バックアップに失敗する

バックアップ機能が途中で止まってしまう場合、zipへの圧縮に失敗している可能性があります。圧縮に失敗する理由として圧縮に一時領域を使用するのですが、サーバーによって一時領域が足りず失敗してしまうことがあります。

これを解決するために、一時的に一時領域の場所を変更することで解決することがあります。

config.server.php に以下1行を追記します。「/path/to/tmp」は環境に合わせたパスを設定ください。(ドキュメントルートの一階層上など)

putenv('TMPDIR=/path/to/tmp'); // ドキュメントルートより上の階層を設定ください

エントリーの自動補完リダイレクト機能

リニューアル時やサイト構造変更時などに、記事(エントリー)のカテゴリーやブログが変更になることはよくあることだと思います。 この時そのままだと、以前のURLが404になってしまいます。404にならなためには、.htaccessなどで旧URLから新URLへのリダイレクト処理を書く必要がありますが、記事ごとに毎回設定するのは大変です。

そこで、エントリーの自動補完リダイレクト機能を使用すれば、ブログやカテゴリーが変更になったエントリーでも自動で旧URLから新URLにリダイレクトをしてくれるようになります。

例:ある記事(entry-10.html)のカテゴリが「news」から「topics」に変更になった場合
「https://example.com/news/entry-10.html」にアクセスすると、「https://example.com/topics/entry-10.html」に自動で301リダレクトされます。

有効化の方法

「private/config.system.yaml」に以下記述を追加します。

entry_301_redirect: on

注意事項

リダイレクトは、エントリーコード(xxxx.html)をもとにデータを検索しリダイレクトをかけています。 この仕様により以下3つの注意点があります。

  • 以前のカテゴリーを削除してしまうとカテゴリーが 404 エラーになってしまいリダイレクトされません。上記の例の場合 news を残して topics を作成ください。
  • エントリーコードを変更した場合は、リダイレクトされない
  • 重複するエントリーコードがある場合、どのエントリーにリダイレクトされるかはコントロールできない