<< 2024/04 >> | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
|
Android端末での BASIC認証後のダウンロード
14/06/28 00:01 / 開発メモ
一つ前の記事で、Android端末で動画ファイルのダウンロードを行おうとすると、download Unsuccessfull となりダウンロードが失敗するのですが、自前HTTPサーバから通信ログを全て出力するようにして、きちんと確認してみた所、以下のような挙動を起すようです。(ある程度省略しています)
01) Connect from 192.168.1.1 02) Recv:GET /download?hogehoge.dat 03) Recv:Host: example.com:80 04) Recv:Connection: keep-alive 05) Recv:Referer: http://example.com/ 06) Recv:Authorization: Basic xxxxxxxxxxxxxxxxxxxxx 07) Recv:Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 08) Recv:User-Agent: Mozilla/5.0 (略) 09) Recv:Accept-Encoding: gzip,deflate 10) Recv:Accept-Language: ja-JP, en-US 11) Recv:Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7 12) HTTP/1.1 200 OK 13) クライアント側から切断されました(10054) 14) Disconnect from 192.168.1.1 15) Connect from 192.168.1.1 16) Recv:GET /download?hogehoge.dat 17) Recv:Host: example.com:80 18) Recv:Connection: Keep-Alive 19) Recv:User-Agent: AndroidDownloadManager 20) HTTP/1.1 401 Unauthorized 21) Disconnect from 192.168.1.1 上から順に追ってみると 1) Android端末の Browser から接続。 2) GET で /download〜を指定 3〜5) 色々送信してくる。 6) BASIC認証を行う。BASIC認証は通過します。 7〜11) 色々送信してくる。 12) HTTPサーバから 200 OK を応答。 13〜14) Android端末の Browser 側から切断。 15) 即座に再接続してくる。 16) 2 と同じ URL を GET してくる。 17〜19) 色々送信してくる。 19 から AndroidDownloadManager が再接続していることがわかります。 20) 認証していないので当然サーバに弾かれます。 21) AndroidDownloadManager は速攻で諦めて切断。 AndroidDownloadManager は認証もなにもしないので、当然ダウンロードできません。 通常の Browser はいきなり認証をしてくるので、Browser 自身は HTTP認証のデータを持っているのですが、AndroidDownloadManager はそのデータにアクセスができない為(おそらくセキュリティの為でしょう。)認証が出来ずに終わるという仕組みのようです。 (それでもプロセス間通信(Androidアプリは殆どやっていないのですが、多分類似的な事はできるでしょう)や、401 応答したら Download Manager で再認証させれば良いのですが、それはやっていない or やらない。ようです) 解決するには・・・ a) BASIC認証をしない。 そのまんまですが、殆ど意味無いですね。 b) BASIC認証しないで、ワンクッションおいたり、Cookie などを使ってセッション管理を行う。 Expire を過去にしたりして、最初に認証した IP アドレスと時間を記録しておき、指定秒数以内であれば、認証を通過させるなどです。 色々と手法はありますが、まぁ普通のセッション管理です。 ワンタイムパスワードなどをサーバ側に記録しておいて、それをセッションIDとして使ってもいいですね。 おそらくですが、通常はこの2つの方法しか回避する策は無いと思います。 そして、行った対策は、折角独自の Web サーバを開発している訳ですので、Web サーバ自身に組み込んでしまいました(笑) やっていることはセッション管理ですが、セッション管理自体を Web サーバ内に組み込んで、BASIC 又は Digest 認証を行ってから指定秒数以内は、同IPからの接続は認証を行わなくてもアクセスできるようにする仕組みです。 簡単に言えばサーバ内部で、認証の有無をセッションに従って動的に切り替えてしまう訳です。 セッションの生存時間は数秒ですが、理論上はセッションが生存している間に(IPパケットを偽装した上で)同一IPからアクセスがあった場合、認証を抜けてしまうセキュリティホールになりますが、現実的にはかなり難しいでしょう。 生存時間を長くすればするほど抜ける確立は高くなりますが、数秒の間ですし、そのタイミングを狙ってアクセスしたとしたら毎秒1回くらいのペースでアクセスをし続ける必要があります。 更に確実性を増すのならば、動的フィルタとかを導入して認証を一定回数失敗したら24時間接続を受け付けないなども導入すればより完全に近くなります。 まぁ、本来はこんなことせずに素直に Download Manager が認証してくれるとか、もしくは Download Manager を Disable にする設定があれば良いだけなんですけどねぇ。 [更新日付:2014/06/28 00:01:09]
トラックバックを見る(0) Log Link [https://akisoftware.com/cgi-bin/blom.exe?akisoft+sl+d82921092bd43c16b58d992fd85da74850b70ab2] TB Link [https://akisoftware.com/cgi-bin/blom.exe?akisoft+tb+d82921092bd43c16b58d992fd85da74850b70ab2] 記事へのコメント コメントはありません |
@AKISoftOfficialをフォロー
掲示板 サポートBBS PMailServer BBS アクセスの多い記事
最新記事(カテゴリ別)
PMailServer2 Version 2.53 をリリースしました。
04/08 00:50 フリー版からの製品版移行時の MTA 並列数について 02/17 23:52 メールサーバーの開発を始めて20年 02/07 21:46 PMailServer2 Version 2.52a をリリースしました。 12/26 14:02 PMailServer2 Version 2.52 をリリースしました。 10/01 10:48 PMailServer2 Version 2.51b をリリースしました。 09/19 01:43 PMailServer2 Version 2.51b(仮) Memo 09/12 00:33 PMailServer2 Version 2.51a をリリース、及び脆弱性についてのお知らせ 09/05 01:15 PMailServer2 Version 2.51a Memo 08/21 00:48 アドレスV125(K5)のスターターリレーの交換 08/04 10:10 最新コメント
コメントはありません
UUアクセス数
今日は 329回
昨日は 432回 トータル 305617回 3ヶ月記事別ランキング
プロフィール
Z80から68系、8086系を経由して
Pascalに移行。現在は Delphiをメインに C/C#も囓ってみたり。 「無い物は作れ」の精神で年がら年中なにかを作っています。 すぐ自前で作りたがるので無駄に工数が上がったりして自爆してみたりもします。 好きな物は麺類とお煎餅 Blom内検索
BLOM Version 1.39 ©2007-15 A.K.I Software all rights reserved. |