Websocket を介して MQTT ブローカーをブラウザーに表示するときに、Mosquitto を保護する最善の方法を理解したいと思います。このブログ投稿に従って、私は現在、websocket レイヤーに Lighttpd を使用しています。
私のユースケースは単方向です。ブラウザにメッセージを送信するだけです。したがって、ACL を使用して、悪意のある人物がメッセージを公開するのを防ぐことができます。
しかし、どうすれば悪党が購読をやめさせたり、そもそも接続を確立したりするのを止めることができるでしょうか?
MQTT 接続に ID/pw を使用できることはわかっています。したがって、ユーザーが自分自身を認証すると、アプリサーバーはブラウザーに資格情報を送信でき、Javascript クライアントはこれらの資格情報を使用して MQTT/WS 接続を確立できると思います。しかし、何千ものクライアントがある場合、ID とパスワードをどのように管理すればよいでしょうか? それとも、ほんの一握りの ID を持っていて、定期的にリサイクルする必要がありますか? mosquitto-auth-plugに従って、このビットを Redis などに渡す必要がありますか?
Webサーバー層内で接続を保護することにより、より良い方法があるかどうか疑問に思いました. Lighttpdのmod_secdownloadプラグインは、共有シークレット (サーバー側で保持) のハッシュとタイムスタンプに基づいて URL を動的に生成できるモデルを提供しているようです。ユーザーが認証されると、アプリ サーバーはこの URL を渡し、クライアントはそれを使用して MQTT ブローカーへの接続を確立します。しばらくすると URL の有効期限が切れ、Javascript クライアントはこの例外をキャッチでき、ユーザーがまだ認証されている場合は、新しい WS 接続 URL を要求できます。これは多くの API 認証に似たパターンです。ここにメリットはありますか？
より良い方法はありますか？
ありがとう、J.