ブラウザからFileMaker CloudのData APIを実行するとCORSエラーになる件と、その認証課題

公開日: 更新日:

ブラウザからFileMaker Data APIは直接実行できない

結論から言うと、ブラウザ(クライアントサイド)からFileMaker CloudのFileMaker Data APIを直接実行すると、CORSエラーになり失敗します。

FileMaker Cloudの場合、ドメイン(your-account.account.filemaker-cloud.com)の配下にユーザー独自のWebアプリを配置したり、サーバー設定を変更したりすることができないため、同一オリジンポリシーの制約を回避する方法がありません。

FileMaker Data API実行時のブラウザコンソールエラー画面
ブラウザからFileMaker Data APIへのログインをテストした結果
クロスオリジン要求をブロックしました: 同一生成元ポリシーにより、https://xxx.account.filemaker-cloud.com/fmi/data/v2/databases/DB_NAME/sessions にあるリモートリソースの読み込みは拒否されます
(理由: CORS ヘッダー ‘Access-Control-Allow-Origin’ が足りない)。ステータスコード: 405
FirefoxコンソールでのCORSエラー詳細(405 Method Not Allowed)

検証環境の準備

Claris ID Tokenの取得

検証にあたり、Claris ID Tokenが必要です。先日公開した以下のツールを使用すると簡単に取得できます。

Generating a Claris ID Token with FileMaker Cloud | frudens Inc.

最近、FileMaker Cloud環境での開発案件が重なり、Data APIを利用する機会が増えてきました。そこで、開発効率を上げるために Claris ID Tokenを簡単に生成できるWebアプリを作成・公開しました。

FileMaker Server環境の場合は、以下のようなcurlコマンドで簡単にセッショントークンが作成できます。

FileMaker CloudのためのClaris ID Token生成アプリを開発・公開しました | 株式会社フルーデンス

検証用HTMLコード

以下のHTMLをローカル環境などで起動することで、挙動を確認できます。
(ソースコードはGistでも共有しています)

Requesting FileMaker Data API login method from a browser results in a CORS error.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Execute FileMaker Data API login method</title>
  <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM" crossorigin="anonymous">
  <style>
    .wrapper {
      max-width: 700px;
      width: 100%;
    }
  </style>
</head>
<body>
<div class="wrapper m-auto mt-3 d-flex flex-column">
  <h1 class="fs-2">Execute FileMaker Data API login method</h1>
  <p class="text-muted">Requesting FileMaker Data API login method from a browser results in a CORS error.</p>

  <h2 class="fs-3 mt-3">Login</h2>
  <div class="border rounded shadow p-3 d-flex flex-column">
    <div class="mb-3">
      <label for="token" class="form-label">Claris ID Token</label>
      <textarea class="form-control" id="token" rows="3"></textarea>
    </div>
    <button class="btn btn-primary" onclick="login()">Login</button>
  </div>

  <h2 class="fs-3 mt-3">Response</h2>
  <div class="border rounded shadow p-3 d-flex flex-column">
    <div class="mb-3">
      <label for="response" class="form-label">Response</label>
      <textarea class="form-control" id="response" rows="3"></textarea>
    </div>
  </div>

</div>

<script>
  const tokenElement = document.getElementById('token');
  const responseElement = document.getElementById('response');
  const ACCOUNT = `your-account`;
  const DB_NAME = `file`; // file.fmp12

  async function login() {
    try {
      const token = tokenElement.value;
      const url = new URL(`https://${ACCOUNT}.account.filemaker-cloud.com/fmi/data/v2/databases/${DB_NAME}/sessions`);
      const response = await fetch(url, {
        method: 'POST',
        headers: {
          Authorization: `fmid ${token}`,
          'content-type': 'application/json',
        },
        body: JSON.stringify({}),
      });
      const data = await response.json();
      responseElement.value = JSON.stringify(data);
    } catch (e) {
      console.error(e);
      responseElement.value = e;
    }
  }
</script>
</body>
</html>
CORSエラーを再現するための検証用HTMLコード

回避策と、その先に待つ「認証の課題」

FileMaker Cloudの場合

前述の通り、FileMaker CloudではSSH接続や設定ファイルの変更が許可されていないため、サーバー設定による回避策はありません。

技術的な解決策としては、ブラウザ -> 中間API(Lambdaや自前サーバー) -> FileMaker Data API という構成(BFF: Backend For Frontend)をとる必要があります。

これによりCORSエラー自体は回避できますが、この構成を採用すると、次は「認証とユーザー管理」という、より複雑な課題に直面することになります。

認証・認可のジレンマ

例えば、フロントエンドで AWS CognitoAuth0 を使ってユーザー認証を行ったとします。その認証済みのリクエストを、バックエンドの FileMaker Data API にどう渡すかが大きな問題になります。

全体構造としては以下のようなイメージになります。

graph TD subgraph Browser ["ブラウザ / フロントエンド"] User["ユーザー"] Auth["Cognito/Auth0認証"] end subgraph Server ["中間サーバー / BFF"] API["中間API (Lambda等)"] end subgraph FMC ["FileMaker Cloud"] DB[("FileMaker Data API")] Log["アクセスログ"] end User --> Auth Auth --> API API -- " パターンA: 共通アカウント実行 " --> DB API -. " パターンB: 個別アカウント連携 (困難) " .-> DB DB --> Log style API fill: #f9f, stroke: #333, stroke-width: 2px style Log fill: #ff9, stroke: #f66, stroke-width: 2px, stroke-dasharray: 5 5 linkStyle 2 stroke-width: 2px, fill: none, stroke: blue; linkStyle 3 stroke-width: 2px, fill: none, stroke: red;
BFF構成における認証フローと技術的課題の構造図

実装パターンと監査ログの壁

実装にあたっては、大きく2つのパターンが考えられますが、それぞれにトレードオフが存在します。

パターンA:API専用の共通アカウントで実行する場合

  • 「API実行用ユーザー」を用意してData APIを叩く方法です。
  • 実装は容易ですが、FileMaker 側の「作成者」「修正者」フィールドには全て「API用アカウント」が記録されます。
  • 「誰がデータを操作したか」をFileMaker標準機能で追跡できなくなるため、別途ログ管理の実装が必要になります。

パターンB:個別のユーザーとして実行する場合

  • 「CognitoのユーザーA」と「FileMakerのユーザーA」を紐付ける必要があります。
  • しかし、FileMaker Cloud の場合、Claris ID の管理が必要であり、Webアプリのユーザー登録と連動して Claris ID を自動発行・同期(CRUD)させることは非常に困難です。

この違いをシーケンス図で表すと以下のようになります。

sequenceDiagram autonumber actor Browser as "ブラウザ (User A)" participant BFF as "中間API (BFF)" participant FMC as "FileMaker Cloud" Note over Browser, BFF: "【前提】フロントエンド(Cognito等)で「User A」として認証済み" rect rgb(235, 245, 255) Note left of Browser: "パターンA:共通アカウント利用
(実装は容易だが監査ログが機能しない)" Browser ->> BFF: "リクエスト" BFF ->> FMC: "Data API実行 (Account: admin)" Note over FMC: "ログ記録:「admin」
(実操作者 User A が特定不可)" FMC -->> BFF: "応答" BFF -->> Browser: "データ返却" end rect rgb(255, 240, 240) Note left of Browser: "パターンB:個別ユーザー連携
(監査ログは正確だが実装困難)" Browser ->> BFF: "リクエスト" BFF ->> BFF: "User Aに対応する
Claris IDを照合" Note over BFF: "⚠️ 技術的な障壁
(外部IdPとClaris IDの同期・招待が困難)" BFF --x Browser: "エラー (アカウント連携失敗)" end
認証方式による監査ログの違いと実装難易度の比較

つまり、「CORSエラーを回避するために中間サーバーを立てる」という選択は、単なるエラー回避ではなく、システムアーキテクチャ全体の複雑性を引き受ける覚悟が必要だということです。

FileMaker Serverの場合

FileMaker Server(オンプレミス等)であれば、以下のいずれかの方法で技術的にはCORS自体は回避可能です。

  • FileMaker Server(Webサーバー)のCORS設定を変更する
  • FileMaker Serverの公開用ディレクトリ(同一オリジン)にWebアプリを配置する

ただし、FileMaker Serverの公開用ディレクトリに独自のWebアプリを混在させる運用や、Webサーバー(IIS/Apache/Nginx)の設定ファイルを直接書き換える行為は、メンテナンス性を著しく低下させます。

FileMaker Serverのアップデート時に設定が初期化されたり、予期せぬ不具合の原因になったりするリスクがあるため、現実的な運用としてはお勧めできません。

FileMaker Serverの設定変更については、以下の記事やコミュニティでの議論が参考になります。

自前の WEB サイトから Data API を呼び出している

自前の WEB サイトのドメインと FileMaker Server のドメインとが異なる

上記の場合、CORS 対応が必要となる

Windows Server ( IIS ) 環境での CORS 対応がややしんどい、知らないと詰む

FileMaker Server の Data API で CORS 対応 #FileMaker - Qiita

I am starting a new web based front end to access my FileMaker data using Angular as the front end framework.

Previously, I had great success with this setup using RESTfm as the backend REST server, but since Angular uses the 'localhost' as it's "server" while building the project, 'localhost' does not match with the DATA API url so my REST Http calls are being blocked by the CORS policy.

I've included an 'Access-Control-Allow-Origin' header with a value of '*', but I continue to get an error that says:

フロントエンドフレームワークとして Angular を使用して、FileMaker データにアクセスする新しい Web ベースのフロントエンドを作成しています。

以前は、バックエンドの REST サーバーとして RESTfm を使用して、このセットアップで大きな成功を収めたのですが、プロジェクトをビルドするときに Angular が「サーバー」として「localhost」を使用するため、「localhost」が DATA API の URL と一致せず、CORS ポリシーによって REST Http コールがブロックされてしまいます。

Access-Control-Allow-Origin'ヘッダーに'*'を指定しましたが、エラーが発生します:

How do you allow for CORS when using the DATA API? | Claris Community

まとめ

「ブラウザからFileMaker CloudのData APIを直接実行したい」というニーズは、シンプルに見えて、実は「セキュリティ(CORS)」と「認証基盤(IdP連携)」という2つの大きな壁に阻まれています。

設定変更による無理な回避は、アップデート時の設定消失リスクなどを伴うため、公式にサポートされている手段ではありません。

個人的な結論としては、「ブラウザからFileMaker CloudのData APIを直接実行することはできない(すべきではない)」と考えます。

安易にCORS回避策を探すよりも、要件定義の段階で「FileMaker Cloudを直接Webフロントエンドから叩く構成に無理がないか?」を見直すことが、プロジェクトを成功させる一番の近道ではないでしょうか。

小巻旭洋のプロフィール写真

小巻 旭洋

2014年からフリーランスとして活動し、2016年に株式会社フルーデンスを設立する。FileMaker開発歴は約10年。多数の企業システム構築を手がけ、特にデータベース設計と、JavaScript連携、Web連携、パフォーマンス最適化を専門としています。2025年から、Web業務システム・アプリ開発をメインに開発をしています。