WebブラウザーでIoTデバイスを検出していますか?


11

最近、Xiaomiからいくつかのwifiリレーを購入しました。これまでのところしっかりしているが、私はXiaomiのアプリが本当に嫌いだ。しかし、私はそれが実際にLANとインターネットの両方で機能するという考えが好きです。Xiaomiのサーバーが中国にあることを考えると、LANに接続しているときは、オンとオフをすばやく切り替えられます。

だから私は自分のESP8266ベースのリレーを使いたいと思っています(ハードウェアを準備できるので、それはおまけです)。私の問題は、Webページからネットワーク上のリレーを自動的に検出するにはどうすればよいですか?

「アプリ」から、SSDP、mDNS-SD、またはUPNPを使用して物事を検出できます。しかし、これがWebブラウザー(基本的にAndroid上のChrome)から可能かどうかについての情報は見つかりませんでした。ウェザーステーションのWebページをプログレッシブWebアプリに変更して以来、夢中になりました。インストールする必要があるアプリではなく、単にWebページであるという考え方が本当に好きです。また、PWAはオフラインモードでもギャップを埋めます。

しかし、奇妙なことに、「難しい」部分(LANの外側からリレーをオン/オフにする)をMQTTサーバー経由で解決するのは簡単です。しかし、私は外部のMQTTサーバーに依存しないことを好みます。LANを使用している場合は、リレーと直接通信したいと思います。そうでない場合は、MQTTを介してコマンドを送信します。

もちろん、リレーにクエリを送信するサーバーに依存することもできますが、その場合はインターネット接続(MQTTサーバーが「クラウド」上にある場合)、またはホームホストサーバーが必要です。私は自宅にサーバーを持っています。持っていなくても、ラズベリーpiは簡単にギャップを埋めることができます。しかし、理想は、LAN(この場合はWifi)を介してデバイスと通信するときにサーバーを必要としないことです。私はそれを可能な限りP2Pに保ち、WANにいるときのフォールバックとしてのみMQTTを使用することを好みます(MQTTはCG-NATおよびポート転送の問題を解決します)。


1
サイトへようこそ、hjf!現在、あなたの質問はかなり広いです。あなたがもう少し具体的であるかもしれないならば、それは役に立ちます:例えば、あなたは現在どの言語を使っていますか、そしてあなたはどんなエラー/特定の問題に遭遇していますか?
anonymous2

1
@ anonymous2まあ、それは非常に一般的な質問です。「ブラウザから直接mDNSクエリを実行できますか」という質問はしたくありません。答えはノーだからです。それに関する標準はありますが、実装はありません。代替機能または同様の機能を探しています。
hjf 2018年

既知のMDNSホスト名は、OSXまたはそれらをサポートするほとんどのLinucesなどのオペレーティングシステムで実行されているブラウザから正常に機能しますが、ブラウジングはおそらく機能しません。そしてもちろん、追加機能がインストールされていない限り、それらはそれらをサポートしないWindowsやAndroidのようなオペレーティングシステムでは動作しません。
Chris Stratton、2018年

回答:


6

ブラウザに組み込まれている一般的なローカル検出機能については知りません。実際には、手動で操作するステップがない限り、攻撃者がネットワークをリモートでプロファイリングできるため、セキュリティの脆弱性であると私は考えています。

近づく2つのことを考えることができます。

  1. ChromecastがChromeに組み込まれました。これは、ロールインされる前は個別のプラグインでした。ただし、これには、ユーザーが検索をトリガーする手動の手順が必要で、その後、ページ/ JavaScriptに渡されるデバイスの詳細を手動で選択する必要があります。(これはカバーIIRCの下でSSDPを使用します)

  2. WebBluetoothスキャンのサポート。これはChromecastディスカバリーと同様のモデルに従います。ユーザーはスキャンを開始する必要があり、ブラウザーで検出されたデバイスから手動で選択して、ページのJavaScriptに詳細を渡す必要があります。

ローカルライトスイッチを発見するためにWebBluetoothアプローチを使用しました(Belkin WeMo電球https://github.com/hardillb/physical-web-lightswitchを制御するpiゼロにBLEアプリがあります)。動作しますが、1つのデバイスを検出するには少なくとも2つのユーザー操作が必要なので、シームレスではありません。

ローカルのすべての要件を満たしているわけではありませんが、ローカルで操作する場合でもクラウドブローカーアプローチを使用すると、よりスムーズなユーザーエクスペリエンスになると思います。


いい答え。探していたのではなかったのですが、それは私が予想していたことです。W3CからのNSD APIがありますが、実装はGoogle Chrome Appsのみです。私
hjf 2018年

NSD APIがドキュメントから削除
hardillb

ここで提案されているセキュリティ理論には、後ろ向きのものが含まれています。問題がある場合、それは発見(ブラウザ)を行うことではなく、それ自体を発見可能にするものです。発見可能性の知恵については、ご自分の意見を歓迎しますが、多くのパーソナルコンピューター、プリンター、およびその他のデバイスの非常に一般的なデフォルトの動作であることは注目に値します。意欲が運営するブラウザの認可何か(かない)を見つけるためのパーティがデバイスを検出するために、不正な当事者の能力については何も言いません。
Chris Stratton、2018年

2

デバイスにWebインターフェイスがあり、bonjourやavahiなどのMDNSレスポンダーサービスを介してMDNSホスト名を持つように構成している場合、機能的なオペレーティングシステムからブラウザーで

https://livingroomlight.local

または、それ自体を呼び出すように構成したもの。

これは、OSX、iOS、およびほとんどのLinucesで実行されているブラウザーでそのまま使用できます。これらはすべて、システムレベルでMDNSホスト名解決をサポートしています。

ただし、これはアドオンMDNSサポートをインストールしない限りWindowsでは機能しません。また、標準のAndroidブラウザーでは機能しませんが、それをサポートするAndroid用のカスタムブラウザーアプリを作成することは可能です。

ネットワーク上の不明なインスタンスの検出は通常、ブラウザーではサポートされていませんが、通常、オペレーティングシステムAPIとdns-sd(OSX)やavahi-browse(Linux)などのコマンドラインツールを介してサポートされています。

したがって、ブラウザがデバイスを見つけることができることは明らかではないようですが、デバイスの1つを何と呼んだかを簡単に覚えることができれば、それに接続でき、MDNSを実行することで、すべてのピアへのリンクを表示できる可能性があります自分自身を検索します。

または、端末を起動して自分自身に答えを得ることができます。さらに言えば、MDNS検索を実行するローカルデーモンを実行して、ループバックインターフェイスでのみ提供されるリンクのページとして結果を表示し、他のマシンからはアクセスできないようにすることができます。


1
残念だ。サポートされている場合、これは代替手段になる可能性があります。ブラウザーでmdns-sdをサポートしない理由は何ですか?とにかく、物事を確実に機能させる唯一の方法は、MQTTを発見方法として使用することだと思います。デバイスが自分自身を報告する何らかの「アナウンス」エンドポイントを用意し、それらの回答をキャッシュします。
hjf 2018年

これは、ブラウザがこれを実行することではありません。これは、オペレーティングシステムのDNSの拡張実装です。つまり、ブラウザ(または他の何でも)はlivingroomlight.local MQTTのような名前を使用できません。ハードウェアボックス、PC上のデーモン、人間のいずれであるかに関係なく、結果を収集して表示します。
Chris Stratton

1
しかし、「アプリ」ではAndroidがmDNSをサポートしています。アプリを介してmDNSクエリを送信し、応答を取得することが可能です。なぜ誰もmDNS-SDを実装してJSに公開しないのですか?特にChromecastを検出するために、部分的にのみ実装された標準がありました。
hjf 2018年

1
繰り返しになりますが、誰もWebブラウザーでMDNSを扱っていないためです。基盤となるオペレーティングシステムのDNSがサポートされるように拡張されている既知のホスト名に対して機能します。Androidはそうではありませんが、別のAndroid固有のAPIを介してアプリにMDNS機能を提供しますが、ドメイン名の解決方法とは関係ありません。
Chris Stratton

1
それが私のポイントです。なぜ誰もこれを求めていないのですか?IoTがますます一般的になるにつれて、この種のAPIがベンダー固有のロックインであり、W3Cが標準を引っ張った可能性はありますか?
hjf 2018年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.