Question 1

なぜ、スケジュールされたAppwrite関数はlocalhostへの'connection refused'で失敗するのですか？

Accepted Answer

セルフホステッドAppwrite 1.9.0では、スケジュールされた関数が実際のAppwriteドメインではなくhttps://localhost/v1に接続しようとする場合があります。これは、スケジューラコンテナに_APP_DOMAIN環境変数が欠けているためです。ワークアラウンド: docker-compose.ymlを編集し、'appwrite-task-scheduler-functions'および'appwrite-task-scheduler-executions'サービスに以下の環境変数を追加します: _APP_DOMAIN、_APP_DOMAIN_FUNCTIONS、_APP_DOMAIN_SITES、_APP_CONSOLE_DOMAIN、_APP_OPTIONS_FORCE_HTTPS、_APP_MIGRATION_HOST、_APP_CONSOLE_SCHEMA。その後、'docker compose up -d'を実行して適用します。これにより、スケジュールされた実行が正しいエンドポイントを使用するようになります。恒久的な修正は、将来のリリースでこれらの変数をデフォルトで伝播することです。

Question 2

Cloudflare SMTP使用時のAppwriteメールタイムアウト「SMTP connect() failed」エラーの修正方法

Accepted Answer

これは、Appwriteのメールワーカーにおいて、Swooleの`SWOOLE_HOOK_SSL`フラグが`ssl://`ストリームを壊すことが原因で発生します（Swoole 5.1.7 + PHP 8.3.17 + OpenSSL 3.3.3）。接続は30秒間停滞した後EOFを返すため、PHPMailerは`SMTP connect() failed` / `Called QUIT without being connected`を報告します。Appwrite 1.7.xでの回避策：両方のワーカーファイルのフックフラグにパッチを適用し、`SWOOLE_HOOK_SSL`も除外してください： ``` MSG= MAIL= # オリジナルをバックアップ docker cp $MSG:/usr/src/code/src/Appwrite/Platform/Workers/Messaging.php ./Messaging.php.bak docker cp $MAIL:/usr/src/code/src/Appwrite/Platform/Workers/Mails.php ./Mails.php.bak # パッチを適用：SWOOLE_HOOK_ALL ^ SWOOLE_HOOK_TCP ^ SWOOLE_HOOK_SSL docker exec $MSG sed -i 's/SWOOLE_HOOK_ALL ^ SWOOLE_HOOK_TCP)/SWOOLE_HOOK_ALL ^ SWOOLE_HOOK_TCP ^ SWOOLE_HOOK_SSL)/' /usr/src/code/src/Appwrite/Platform/Workers/Messaging.php docker exec $MAIL sed -i 's/SWOOLE_HOOK_ALL ^ SWOOLE_HOOK_TCP)/SWOOLE_HOOK_ALL ^ SWOOLE_HOOK_TCP ^ SWOOLE_HOOK_SSL)/' /usr/src/code/src/Appwrite/Platform/Workers/Mails.php docker restart $MSG $MAIL ``` 元に戻すには、.bakファイルを`docker cp`で書き戻して再起動してください。注意：これは`Messaging.php`（96行目）と`Mails.php`（53行目）の両方に影響するため、この修正を適用しないと、認証メールやパスワードリカバリーメールも機能しません。メンテナーによると、AppwriteはPHPMailerを使用しなくなったためmainでは修正済みであり、アップグレードが恒久的な解決策となります。

Question 3

Appwrite SitesでNext.jsモノレポをデプロイする際の「mv: can't rename '/usr/local/build/next.config.*': No such file or directory」エラーの修正方法

Accepted Answer

このエラーは、Next.js アプリがリポジトリのルートではなくモノレポのサブディレクトリ（例：`./apps/web`）に配置されている場合に、SSR バンドリング中に発生します。Open-runtimes は、アプリのサブディレクトリではなく、ビルドルート（`/usr/local/build/`）で `next.config.*` を探していました。この問題は open-runtimes の PR #575（open-runtimes/open-runtimes#575）で修正されたため、更新されたランタイムでサイトを再デプロイしてください。モノレポの正しいビルド設定は次のとおりです：ルートディレクトリを `./` に設定し（bun/npm がワークスペースの依存関係を解決できるようにするため）、出力ディレクトリを `./apps/web/.next` に設定し、Next.js アプリの前にワークスペースの依存関係をビルドするビルドステップを含めてください。

Question 4

Appwrite SDK の README が生成後に間違ったサーバーバージョンを示す場合、どう修正すればよいですか？

Accepted Answer

バナーは、仕様の実際の info.version（たとえば 2.0.0）ではなく、誤って --version の仕様フォルダー名（たとえば 1.9.x）から取得されていました。これは PR #14305 で修正されています: SDKs::getServerVersion() は info.version を解析し、major.minor.x に縮約します。たとえば 2.0.0 → 2.0.x、2.4.3 → 2.4.x です。静的仕様の SDK は引き続き --version を使用します。SDK ジェネレーターをマージ済みの修正に更新し、その後 SDK を再生成してリリースしてください。すでに公開された README に対する一時的な回避策として、サーバーバージョンのバナーを手動で修正してください。

Question 5

Appwriteのユーザー登録にCAPTCHA（reCAPTCHA、hCaptcha、Turnstile）を追加してボットによるサインアップをブロックする方法

Accepted Answer

AppwriteにはまだネイティブなCAPTCHA統合がありません（機能リクエスト #5384 はまだオープン状態です）。Appwrite Functionを使用した公式の回避策：

1. Appwrite Consoleで Auth > Security に移動し、「Users Limit」を1に設定します。これにより、すべてのクライアント側のアカウント作成がブロックされ、ボットがAPI経由で直接登録できなくなります。
2. CAPTCHAウィジェット（Cloudflare Turnstile、hCaptcha、またはreCAPTCHA）をクライアント側の登録フォームに追加します。
3. クライアントからCAPTCHAトークンとメールアドレス、パスワード、名前を受け取るAppwrite Functionを作成します。
4. 関数内で、シークレットキーを使用して、プロバイダーのsiteverifyエンドポイント（例：https://challenges.cloudflare.com/turnstile/v0/siteverify または https://hcaptcha.com/siteverify）に対してトークンを検証します。
5. 検証が成功した場合のみ、APIキーを使用したAppwrite Server SDKで users.create() を呼び出してアカウントを作成します。それ以外の場合はリクエストを拒否します。

注意点：Users Limitを1に設定すると、すべてのクライアント側のサインアップが無効になるため、初回のOAuth/SSOログイン（これもユーザーを作成します）も影響を受ける可能性があり、同様に関数経由で処理する必要があります。

Appwrite

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト