33

クライアント プロジェクトの場合、非常に単純な機能を提供する単純なハイブリッド アプリを作成していますが、トラフィックが多くなります。アプリは非常にシンプルで、firebase はプロジェクトにとって完璧なソリューションのように見えるため、通常はバックエンドは必要ありません。

私が立ち往生している唯一の部分は、FirebaseによるSMS検証/認証です。ただし、いくつかの激しいグーグル検索とドキュメントの読み取りの後、これを行う簡単な方法がないことに気付きました。これまでに調べたことは次のとおりです。

  1. Fabric.io Digits には優れた JS API がありますが、何らかの理由で firebase と数字がうまく連携しません: https://groups.google.com/forum/#!topic/firebase-talk/sB7lPuyCVBQ
  2. Facebook アカウント キット- ほんの 1 週間前、Facebook は SMS 検証と認証用の新しいキットをリリースしましたが、少なくとも別の方法で証明されるまでは、fabric.io 数字と同じ問題があるように感じられます。
  3. NodeJS 経由の Twilio / Nexmo - これらは両方とも優れた JS API を備えた壮大なサービスですが、私が理解していることから、これには JWT トークン交換を処理するための別のバックエンド サーバーが必要です。そして、それ自体が別のサーバーであり、トラフィックが多いときにボトルネックになり、セキュリティの別の脆弱性ポイントになるため、クライアント チームは個別に管理する必要があります。最も快適ではありません。
  4. Twilio / Nexmo & Auth0 - これまでのところ、認証とユーザー管理が Auth0 によって処理されるこれが最良のオプションのように思えますが、twilio または nexmo と auth0 の両方が有料ソリューションであることを考えると、このソリューションはすぐに高価になる可能性があります。私は物事が無料で機能することを安っぽく期待しているわけではありませんが、トークンを転送するだけであることを考えると、非常に高価な追加のステップのように感じます. [参照: 地獄からのクライアント]
  5. 123-456-7890@example.com のように、電話番号を firebase のメールとして使用し、SMS で送信されたセキュリティ コードをパスワードとして使用するなどの提案をどこかで読んだことを覚えています。

通常、ハイブリッド モバイル アプリの場合、非ネイティブな性質または JS API が原因ですが、初めて (少なくとも私にとっては) そうではないと感じました。現時点では、Firebase は有効な選択肢ではないと思いますが、AWS を調べ始め、クライアントのバックエンド全体をセットアップする前に、愛情と思いやりのあるコミュニティのメンバーに最後にもう一度尋ねたかったのです。

このタイプの認証をミドルサービスなし/バックエンドサーバーなしで処理する他の方法はありますか? これらのソリューションを使用した経験がある人はいますか?

更新: 2017 年 5 月

電話の確認と認証が、Firebase でネイティブに利用できるようになりました。以下の私の自己投稿の回答を参照してください。

更新：2017年4月

Firebase はCloud Functionsをネイティブにサポートするようになりました。サーバーをセットアップせずに、Cloud Functions を使用してこれを実現し、さらに多くのことを実現できるようになりました。

更新：2017年10月

Fabric.io と Firebase は、Firebase の電話認証で Digits を連携および統合し、Fabric の追加機能をリリースしました。

4

4 に答える 4

2

あなたが言及したすべての統合についてお話しすることはできませんが、Twilio の別のサービスである Authy を試してみることをお勧めします。

最近、この種の問題を解決するのに役立つチュートリアルを介して、本番環境に対応したコード サンプルをリリースしました。

そのような例の 1 つを説明します。

  • OneTouch プッシュ通知をモバイル Authy アプリに送信する、または
  • モバイル Authy アプリまたは
  • Twilio を介して Authy で送信されるテキスト メッセージでワンタイム トークンを送信します。

は、Authy チュートリアルを使用した 2FAです。次の Node.js スニペットは、ユーザー ステータスが承認または拒否されるのを待っているエンドポイントを示しています。ユーザーが OneTouch リクエストを承認した場合、セッションを として保存しconfirmed、正式にログインします。

リクエストが拒否された場合は、/verifyページをレンダリングし、ユーザーにトークンを使用してログインするように求めます。

// Internal endpoint for checking the status of OneTouch
exports.authyStatus = function(request, response) {
    var status = (request.user) ? request.user.authyStatus : 'unverified';
    if (status == 'approved') {
        request.session.confirmed = true;
        request.session.save(function(err) {
            if (err) return error(response, 500, 
                'There was an error validating your session.');
        });
    }
    if (!request.session) {
        return error(response, 404, 'No valid session found for this user.');
    } else {
        response.send({ status: status });
    }   
};

したがって、これには実際にサーバーが必要です。しかし、サンプルを試してみると、アプリに最適なものを判断するのに役立ちます。

于 2016-04-18T22:39:19.853 に答える