接続とノード登録のためにセレンのグリッドに安全な認証を設定する方法は？

Question

私は、異なるチームに奉仕するセレングリッド（3.1.0）をセットアップしています。チームにグリッドURLを公開する前に、私は、グリッド接続がハブにノードを登録するには、認証を必要とすべきである

1. 以下のようにいくつかのセキュリティ対策を作りたいです。 （外部の登録を避けるため）

2. また、グリッドに到達するために認証が必要です（資格証明は機能を通過する必要があります）。

現在、インフラは

ハブです：LinuxのRHEL7 ノード：窓10 セレン：3.1.0

いくつかのアイデアを得るために私を助けてください。

FYI：セレンプロジェクトを再構築しようとしましたが、これは時間がかかった複雑な試みだと思っていました。

おかげで、あなたはそれを行うようになる

Answer 1

私の知る限り

何がそこにありません。つまり、あなた自身でこれを構築することができます。あなたの最初の要件すなわちを達成するために

。、

グリッド接続がハブに ノードを登録するための認証を要求する必要があります。

ここ

は、あなたがそれを行う方法です（外部登録を避けるために）（簡単のために、私は上の別の質問から私の答えを貼り付けコピーしていSO hereから）（

• が新しいマーカーインターフェイスを作成します。 Registrableと呼んでください）
• 内容がorg.openqa.grid.selenium.proxy.DefaultRemoteProxyの内容を複製する新しいクラスを作成します（私はこのアプローチをCLASSPATHオーバーライドと呼んでいますが、これにはもっとエレガントな名前が必要です）。この新しいクラスも呼び出されますDefaultRemoteProxyと同じパッケージにありますorg.openqa.grid.selenium.proxyですが、テストプロジェクトにあります。
• コンストラクタ内で、次に示すように編集チェックを追加します。
• このプロジェクトからuber jarを作成し、それを使ってハブをスピンオフすることができます。ここで

は次のようになりますどのようにRegistrableです

public interface Registrable {}

ここ

ようDefaultRemoteProxyの変更コンストラクタがどのように見えるかです：あなたはそれを実装するようにカスタムプロキシを微調整することができます今すぐ

public DefaultRemoteProxy(RegistrationRequest request, Registry registry) { 
super(request, registry); 
if (!(this instanceof Registrable)) { 
    throw new UnsupportedOperationException("Cannot proceed further"); 
} 
pollingInterval = config.nodePolling != null ? config.nodePolling : DEFAULT_POLLING_INTERVAL; 
unregisterDelay = config.unregisterIfStillDownAfter != null ? config.unregisterIfStillDownAfter : DEFAULT_UNREGISTER_DELAY; 
downPollingLimit = config.downPollingLimit != null ? config.downPollingLimit : DEFAULT_DOWN_POLLING_LIMIT; 
} 

Registrableインターフェイス。したがって、DefaultRemoteProxyを使用してノードを登録しようとする人は、がRegistrableインターフェイスを実装していないため、常に失敗します。これは、基本的に、このカスタムプロキシーの実装がなくても、人々が自分のノードをハブに登録しようとすることを防ぎます。 2番目の要件すなわちを達成するために

。、

はまた、グリッドに到達するために必要な認証（資格情報は機能によって を渡す必要があります）。次のようにあなたがそれを行うことができます

：

• ユーザーがRemoteWebDriverインスタンスをインスタンス化する際にそのDesiredCapabilitiesにいくつかのカスタムキーを追加する必要があります。これらのカスタムキーは実際にはユーザーが渡すことができるユーザー名とパスワードの組み合わせである可能性があります。
• グリッド側では、org.openqa.grid.internal.BaseRemoteProxy#hasCapabilityメソッドをオーバーライドするカスタムプロキシーの実装を作成する必要があり、その中に入ってくるrequestedCapabilityをそれがキー（資格情報）を持っているかどうかをチェックし、（データベースやその他の選択したデータソースと照合して）検証し、そうでなければfalseを返します。キーが存在し、有効な場合は、機能一致をsuper.hasCapability()への呼び出しに委任します。

このようにして、受信機能にあなたが探している認証メカニズムがない場合、グリッドは、グリッドの機能と一致しないという新しいセッション要求を拒否します。

それはあなたのためのトリックを行う必要があります。