伊藤です。
https://github.com/sample-by-jsakamoto/Selenium-E2ETest-for-OTP2FAAuth/blob/master/OTP2FAAuthWebAppDemo.E2ETest/appSettings.json
のotpKeyにサーバサイドで利用しているのと同じシークレットキーを設定しておき、
ですです。
あまり大した解説も付けていないのに読み解いていただいて大変恐縮です。
もう少し付け足すと、この "サーバーサイドで利用しているのと同じシークレットキー" というのは、「Authenticator モバイルアプリで、このQRコードをスキャンしてね」というときの、あの QR コードに埋め込まれているコードです。
そしてそのような二要素認証セットアップページには、QRコードが読めなかった場合に備えて、「キーを手入力するときはこれを入れてね」と英数字の羅列が表示されているはずなのですが(そして Authenticator モバイルアプリにも、QRコードを撮影するだけでなくキーを手入力するオプションが用意されています)、実のところその英数字の羅列が "サーバーサイドで利用しているのと同じシークレットキー" です (Base32 でエンコードしたものです)。
appSettings.Development.json に、上記、二要素認証セットアップページに掲載の「キーを手入力するときはこれを入れてね」の英数字の羅列を設定すれば OK、というのは、そういう仕組みだからなのでした。
のロジックを呼び出せば、その時点でサーバで計算されているのと全く同じ認証コードが
クライアント側でも取得できるということでしょうか。
まったくもってそのとおりです。
別の言い方をすれば、Google Authenticator モバイルアプリを、テストプログラムに内蔵したようなものです。
On Monday, January 15, 2018 at 9:28:51 PM UTC+9,
kanat...@gmail.com wrote:
拝見させていただきました。
すごいですね。こんなことできるんですね!
はいー。
こういうことができることを知らないときは「おおっ!」と思いますが(私もこれを知った時に「おおっ!」と思いました :) )、実は Google Authenticator モバイルアプリがやってる仕組みって、プログラマ的には難しくなかったんですね。
私もサンプルコードとしてまとめはしましたが、このワンタイムパスワードを計算してくれるライブラリが公開されているおかげで、キモの部分はたかだか2~3行程度で済んでしまってます。
繰り返しになってしまいますが、こういうこと( Authenticator モバイルアプリと同じ機能をテストプログラムに内蔵して、二要素認証を正面突破する方法 ) が "できる" からといって、"そうすべき" ということにはならないとは思ってます。
profile 指定や cookie 設定の技法も、認証済みの状態をつくりあげることで認証画面をスキップしてテスト対象を実行できるので、テストの消化速度があがる・未認証かどうかの判定不要で安定したテストが書ける、など、利点も多いと思います。
月並みな感想ですが、どの技法を選択するかは結局はケースバイケース、っていうのが今のところの自分の結論です。