プッシュ通知と Spring Cloud Bus

多くのソースコードリポジトリプロバイダー（Github、Gitlab、Gitea、Gitee、Gogs、Bitbucket など）は、Webhook を介してリポジトリの変更を通知します。プロバイダーのユーザーインターフェースを介して、関心のある URL および一連のイベントとして Webhook を構成できます。たとえば、Github (英語) は、コミットのリストと push に設定されたヘッダー（X-Github-Event）を含む JSON 本文を使用して Webhook への POST を使用します。spring-cloud-config-monitor ライブラリへの依存関係を追加し、構成サーバーで Spring Cloud Bus をアクティブ化すると、/monitor エンドポイントが有効になります。

Webhook がアクティブ化されると、構成サーバーは、変更された可能性があると思われるアプリケーションを対象とした RefreshRemoteApplicationEvent を送信します。変更の検出は戦略化できます。ただし、デフォルトでは、アプリケーション名に一致するファイルの変更を検索します（たとえば、foo.properties は foo アプリケーションを対象とし、application.properties はすべてのアプリケーションを対象とします）。動作をオーバーライドする場合に使用する戦略は PropertyPathNotificationExtractor です。これは、リクエストヘッダーと本文をパラメーターとして受け入れ、変更されたファイルパスのリストを返します。

デフォルトの構成は、Github、Gitlab、Gitea、Gitee、Gogs、Bitbucket でそのまま使用できます。Github、Gitlab、Gitee、Bitbucket からの JSON 通知に加えて、path={application} のパターンでフォームにエンコードされた本文パラメーターを使用して /monitor に POST することにより、変更通知をトリガーできます。そうすることで、{application} パターン（ワイルドカードを含めることができる）に一致するアプリケーションにブロードキャストします。

RefreshRemoteApplicationEvent は、構成サーバーとクライアントアプリケーションの両方で spring-cloud-bus がアクティブ化されている場合にのみ送信されます。
デフォルト設定では、ローカル git リポジトリのファイルシステムの変更も検出されます。その場合、Webhook は使用されません。ただし、構成ファイルを編集するとすぐに、リフレッシュがブロードキャストされます。

Webhook シークレットの検証

認証されていないユーザーが設定のリフレッシュをトリガーするのを防ぐため、構成サーバーは、リポジトリプロバイダで設定された共有シークレットに対して、受信した Webhook リクエストを検証できます。プロバイダにシークレットが設定されている場合、/monitor エンドポイントは、有効な署名またはトークンを持たないそのプロバイダからのリクエストを拒否し、HTTP 403 を返します。

シークレットが全く設定されていない場合、/monitor エンドポイントはすべての受信 Webhook リクエストを拒否します。受け入れたい Webhook を提供するプロバイダーごとに、Webhook シークレットを設定する必要があります。

各プロバイダーは、リクエストに署名するために異なるメカニズムを使用します。構成サーバーは、以下のメカニズムをサポートしています。

プロバイダー 機構 プロパティ

GitHub

X-Hub-Signature-256 ヘッダーに sha256=<hex> として送信された、生のリクエストボディの HMAC-SHA256。

spring.cloud.config.server.monitor.github.webhook-secret

GitLab

X-Gitlab-Token ヘッダーにそのまま平文の秘密トークンが送信されました

spring.cloud.config.server.monitor.gitlab.webhook-secret

Bitbucket クラウド

X-Hub-Signature ヘッダーに sha256=<hex> として送信された、生のリクエストボディの HMAC-SHA256。

spring.cloud.config.server.monitor.bitbucket.webhook-secret

Bitbucket サーバー / データセンター

X-Hub-Signature ヘッダーに sha256=<hex> として送信された、生のリクエストボディの HMAC-SHA256。

spring.cloud.config.server.monitor.bitbucket.webhook-secret

ゴグス

X-Gogs-Signature ヘッダーで送信される、生のリクエストボディの HMAC-SHA256 ハッシュ値 (接頭部なし)

spring.cloud.config.server.monitor.gogs.webhook-secret

ギテア

X-Gitea-Signature ヘッダーで送信される、生のリクエストボディの HMAC-SHA256 ハッシュ値 (接頭部なし)

spring.cloud.config.server.monitor.gitea.webhook-secret

ギティー

下記 Gitee validation modes を参照

spring.cloud.config.server.monitor.gitee.webhook-secret

Gitee Validation Modes

Gitee supports two webhook authentication modes, selected by whether the X-Gitee-Timestamp header is present in the request:

  • Signature mode (推奨): When X-Gitee-Timestamp is present, the X-Gitee-Token header contains a Base64-encoded HMAC-SHA256 of <timestamp>\n<secret>, keyed with the secret. The Config Server also rejects requests whose timestamp differs from the server clock by more than one hour.

  • Password mode : When X-Gitee-Timestamp is absent, the X-Gitee-Token header is compared directly against the configured secret.

Configure the mode on the Gitee webhook settings page. Signature mode is recommended because it prevents replay attacks.

Disabling Webhook Validation

The validation filter is enabled by default. To disable it entirely, set:

spring:
  cloud:
    config:
      server:
        monitor:
          validation-filter-enabled: false

You can also disable validation for a specific provider while keeping its webhook events processed, by setting its validation-enabled property to false:

spring:
  cloud:
    config:
      server:
        monitor:
          github:
            validation-enabled: false

To disable a provider’s /monitor integration altogether (both validation and event processing), set its enabled property to false:

spring:
  cloud:
    config:
      server:
        monitor:
          github:
            enabled: false