Dig into the Heroku AppLink (not a deep dive) - サービスメッシュについて

Heroku AppLinkを導入するにあたり、heroku-applink-service-mesh をビルドパックとして追加するようドキュメントに明記されている。
https://devcenter.heroku.com/articles/getting-started-heroku-applink-agentforce#install-the-heroku-applink-buildpack
このサービスメッシュの役割について少し触れてみよう。

サービスメッシュは、Heroku RouterとHerokuアプリケーション(自前で作るアプリケーション)の間に入って、HerokuアプリケーションのAPIを守る役割を持っている。

大まかに言えば以下のような流れとなる。

  1. 外部からのリクエストが、Heroku Routerにやってくる
  2. Heroku Routerがweb dynoに向かってリクエストを転送する
  3. web dynoに組み込まれたサービスメッシュが、リクエスト内容をチェックする
  4. リクエスト内容がokであれば、Herokuアプリケーションにリクエストを転送する
  5. リクエスト内容がngであれば、Heroku Routerに401エラーを返して、Herokuアプリケーションには転送しない

サービスメッシュがリクエスト内容をチェックすることでHerokuアプリケーションのAPIをセキュアにするという仕組みである。

※さらに、リクエスト内容がokの場合、リクエストヘッダに値をセットしてくれるので、Herokuアプリケーション側でsdkを使うと、リクエストヘッダ内の値からアクセストークンが取得できるようになる。結果として、HerokuアプリケーションからもSalesforceへのクエリやデータ操作が可能となる。

Heroku AppLinkの世界では、「外部からのリクエスト」とはSalesforceからのリクエストを想定している。したがって、Salesforceからのリクエストであれば、サービスメッシュ内のプログラムがokと判定(サービスメッシュ内でどのように判定しているのか...その詳細な実装については不明)して、Herokuアプリケーション側の処理が実行される。

こうすることで、Herokuアプリケーション側ではリクエストに対するチェック機構を自前で用意することなく、APIの実装に注力することができる。

これまで、Salesforceの機能拡張としてHerokuアプリケーションを活用しようにも、Herokuアプリケーション側には認証機構が必要だった。
しかし、Heroku AppLinkの世界では、HerokuアプリケーションのAPIへのセキュリティはSalesforceとHerokuが担保してくれるので、自前で認証機構を用意する必要がなくなる、という大きなメリットがある。

Heroku AppLinkを導入すると、Heroku Routerからやってくるリクエストを全てサービスメッシュが一旦受け取って、認証チェックを行う。

構築しているHerokuアプリケーションが、Salesforceからのリクエストのみを受け付けるもの、という前提があるならそれで問題ない。

しかし、特定のAPIは別のWebサービスからのリクエストを処理したい...という場合には非常に困るのである。

例えば、一般公開しているECサイトの商品データを返すAPIと、Salesforceからしか受け付けないAPIを、1つのアプリケーションに同居させたい場合がこれにあたる。
一般公開しているECサイトは、当然ながらSalesforceの認証情報なんぞ持っていない。したがって、そんなサイトからのリクエストはサービスメッシュが拒否してしまい、サイトに商品データを表示することができなくなる。

こんな場合、Herokuアプリケーション側で特定のURLパターンではサービスメッシュをバイパスするよう設定することができる(ようになった)。

1. バイパス用の設定ファイルを設置する

Herokuアプリケーションのrootディレクトリに、heroku-applink-service-mesh.yaml というファイル名で、以下のようなyamlファイルを用意する。
※ファイル名が違うと設定が読み込まれない
バイパスしたいURLパターンや、URLを列挙しておく。

mesh:
  authentication:
    bypassRoutes:
      - "/app/**"
      - "/admin/**"
      - "/auth/**"
      - "/box/**"
      - "/salesforce/**"
      - "/store/**"
      - "/custom/**"
      - "/hooks/**"
      - "/favicon.ico"
      - "/robots.txt"

2. 環境変数を定義する

HEROKU_APPLINK_SERVICE_MESH_ACKNOWLEDGE_RISK_BYPASS という名前の環境変数を用意して、 true をセットする。
バイパスするリスクは認識していることを明示する...という具合だ。

上記の設定が完了してHerokuアプリケーションを起動すると、以下のようなログが出力される。

xxx xx 00:00:00 (heroku app name) app/web.1 level=WARN msg="Authentication bypass routes: /app/**, /admin/**, /auth/**, /box/**, /salesforce/**, /store/**, /custom/**, /hooks/**, /favicon.ico, /robots.txt" app=(heroku app name) source=heroku-applink-service-mesh

そして、バイパスに設定したAPIへのリクエストがあると、以下のようなログが出力され、確かにサービスメッシュの処理がスキップされる。

xxx 00 00:00:00 (heroku app name) app/web.1 level=INFO msg="Processing request to /store/product-categories..." app=(heroku app name) source=heroku-applink-service-mesh request-id=d85d442d-4216-1b1d-9916-312219e76156
xxx 00 00:00:00 (heroku app name) app/web.1 level=WARN msg="Bypassing validation and authentication for route /store/product-categories" app=(heroku app name) source=heroku-applink-service-mesh request-id=d85d442d-4216-1b1d-9916-312219e76156
xxx 00 00:00:00 (heroku app name) app/web.1 level=INFO msg="Forwarding request..." app=(heroku app name) source=heroku-applink-service-mesh request-id=d85d442d-4216-1b1d-9916-312219e76156

もちろん、1つのHerokuアプリケーションに同居させなければ、バイパス設定は不要になるが、もし!どうしても!同居させたい場合にはこういう裏技的な設定が必要になる。

ご利用は計画的に。

Read more

heroku

Dancing with Heroku AppLink / 2

(ローカルアプリと組み合わせる...?) 構成の概要 Heroku AppLinkの活用例として、こんな構成を試してみた。 * 個別に作成したElectronアプリケーションがあって、そのアプリケーションはSalesforceのデータを参照したり、データを作成する。 * Electronアプリケーションに、Salesforceのアクセストークンを持たせてアクセスできるようにしたい。 * しかし、Electronアプリケーション内にSalesforceのアカウント情報を持たせたくないし、個別のログイン機能なんて作りたくない。 * Electronアプリケーションに渡す情報にはSalesforce外の情報もあり、その諸々の情報をまとめるためにHerokuアプリケーションを設置した。 * (Apexコードを書くのがやや面倒...) といったあたりで、上のような構成を試してみた。 Heroku AppLinkの活用ポイント など ※主に②で大活躍するので、そこに絞った話をしてみよう。 まず、Heroku側の実装としては以下を前提として、Node.jsアプリケ

By Takahiro Yonei

heroku

Dancing with Heroku AppLink / 1

(まずはよくありそうなパターンでも) 構成の概要 Heroku AppLinkの活用例として、こんな構成を試しているところ。 * HerokuとSalesforceを組み合わせて上のようなWebシステムを構築してる。 * HerokuはFrontend(Next.js)とBackend(Medusa.js)を使ってアプリケーションを作成している。 * Salesforceで作成したデータをHeroku Backendに連携する。BackendのAPIを外部サービスとしてSalesforceに登録しておいて、SalesforceからはFlowを使って連携する。 * Fronendから送信されたデータは、Backendを介してSalesforceに連携する。Heroku AppLinkを使ってSalesforceへのアクセストークンを取得してSalesforceにデータを書き込む。 構成としては、よくありそうなパターンではなかろうか。 しかし、Heroku BackendにAppLinkを組み込むことで、BackendとSalesforceの実装工数を削減で

By Takahiro Yonei

Dancing with Heroku vibes / 2

heroku vibesの画面操作を見るに、プロンプトを入力しつつ1つのherokuアプリを自動生成していくように見える。 1つのアプリで完結するようなものであれば、それでも良さそうに思える。 しかし、複数のherokuアプリを組み合わせてシステムを構築することもあるので、その場合はどうサポートしてくれるだろうか? プログラマの視点からすると、アプリの自動生成については...あまり優位性が見出せない。 pipelineを使いたいとかgithubとの連携とかあるので、自分でやった方が良いかなぁと思う。その辺りはむしろheroku MCPサーバの方がやりやすいかもしれない。 ボンヤリとしたアイディアから、構成や使用するadd onをいい感じに提案してくれる壁打ち相手として使えそうだろうか?と思う。 プログラマでない人からすれば、herokuアプリを自動生成してくれるのは助かる場面はありそうだ。 ただの想像だけど、salesforceを拡張する機能としてheroku applinkを使ったherokuアプリを自動生成する...みたいな場面であれば、プログラマでない人には有益かもしれない

By Takahiro Yonei