7

https callbackUrl の制限とサブスクリプション全体の性質により、これはパブリックにアクセスできる URL でのみ実行できるように思えます。

これまでのところ、ローカルでの開発とデバッグを容易にする 2 つの解決策を見つけました。

1 つ目は、Google が提供するサブスクリプション プロキシサービスです。この回避策により、基本的に、カスタム URL への SSL 制限とプロキシ サブスクリプション コールバックを削除できます。

開発をローカルで行うために私が見つけた 2 番目の最も役立つ方法は、サブスクリプションのコールバック要求 (パブリックにアクセス可能なサーバーからなど) をログにキャプチャし、curl を使用してローカル/開発マシンでその要求を次のような方法で再現することです。 :

curl -H "Content-type: application/json" -X POST \
  -d '{"json for":"the notification"}' http://localhost:8080/notify

リクエストが大きくなる場合や、複数のコールバック タイプをテストする場合があるため、添え字リクエストの JSON をさまざまなファイル (例: timeline-respond.json) に入れてから実行すると便利であることがわかりました。

curl -H "Content-Type: application/json" \
  --data @timeline-respond.json http://localhost:8080/notify

アプリケーションのサブスクリプションをローカルでテストするために、他の人が何をしているのか気になります。

4

2 に答える 2

3

あなたが言及したコマンドラインのcurl手法は、私がこれまでに見つけた中で最高のものです.

App Engine サブスクリプション ターゲットをローカル スクリプトと組み合わせて、新しい通知を に中継するためにその App Engine サービスをプルするなど、他のソリューションを試してみましたlocalhostが、これまでのところ、追加の複雑さに見合うものは見つかりませんでした。

または、利用可能な localhost プロキシが多数あります。私のお気に入りはngrok.comです。

于 2013-06-03T23:17:42.953 に答える
0

localtunnelを試してみてください。

于 2013-12-07T14:39:39.677 に答える