隙あらば寝る

うぇぶのかいしゃではたらくえんじにあがかいています

はてなブログhttps化

なんとなく書かなくなって随分と経ってしまった。

そんな時この記事を見つけて良い機会なので更新。

staff.hatenablog.com

ついにhttps対応してもらえるらしい。

技術的な説明はさすがという印象。

今これを書いている管理画面もそのうち変るのかな。

色々大変そうな部分は痛いほどわかるので関係者の皆様には頑張って頂きたい。

リンクを作る時の target="_blank" の危険性

html で リンクを新しいタブ(やウィンドウ)で開かせたい場合、target="_blank" を指定するが、

この使い方には落とし穴があるらしい。

www.jitbit.com

リンクを開いた先の javascript から、開いたのページを操作できてしまうとのこと。

気になったので確認してみた。

悪用のパターン

f:id:yoru9zine:20170317225519p:plain

insecure.html が最初に開くページで、ここに target="_blank" なリンクがある。

このリンクを押すと new_window.html を新しいタブで開く。

この new_window.html に javascript が仕込まれており、元ページを操作されるという話。

具体的には window.opener.location="./evil.html" と実行すると、元タブは evil.html に遷移する。

実際試してみたのが ここ

リンクを開くとたしかに元タブで遷移が発生した。

なるほどこんな事ができたのか。。。

予防

予防するには target="_blank" なリンクに対して rel="noopener noreferrer" を設定すれば良いとのこと。

f:id:yoru9zine:20170317230021p:plain

実際ためしたのが ここ

問題の javascript は以下のエラーで停止した。(Chrome 56.0.2924.87 で確認)

Uncaught TypeError: Cannot set property 'location' of null
    at new_window.html:4

まとめ

自分の管理下にあるサイトであればリスクはかなり低いと思われる。

一方で外部へのリンクをtarget="_blank" で作成している場合は対策を行っておいたほうが良い。

リスクとしては参考URLで解説されているように、元サイトそっくりに作られたフィッシングサイトにパスワード等を入力してしまう恐れがあるというのが最も想像し易い。

また、管理下にあるリンク先だとしても、利用者が任意のコンテンツを置ける場合や乗っ取られる場合もあるので一律で対策するのが良さそうだ。

もくじでジャンプ

TV SideView のお知らせで「もくじでジャンプ」機能の終了予告が来ていた。

info.tvsideview.sony.net

番組の特定のコーナー等に直接飛べるので重宝していた。

とはいえ再生さえ初めてしまえばチャプタージャンプで十分なのでそんなには困らない。

ちょっと残念だけどしょうがない。

iOS の Video & TV Sideview 4.7 で課金プレイヤーが使えなくなった話

先に結論。

復元時に App Store に接続できません と言われて復元できない人は

iOS の設定から iTunes & App Store で一度サインアウト、その後もう一度サインインする。その後復元すればOK

nasne の番組を iPhone から見るために、iOS の Video & TV Sideview をインストールして使っている。

プレイヤーは有料なのでアプリ内課金していた。

最近 4.7 に上がったが、どうもそれ以来再生時に課金したプレイヤーが使えなくなっている。

当然こないだまでは再生できたいたわけで、どうせ復元すれば治るだろうと思って復元を押しても

App Store に接続できません

と言われて無限にエラー。

おやおやとアプリのレビューを見てみると案の定同じような状況で文句を言っている人がいる。

(レビューの場所に書いても相手からは返事もらえないから問い合わせしたほうがいいよと思いつつ。。。)

で、最終的には

info.tvsideview.sony.net

に解決方法が載っていた。

iOS の設定から iTunes & App Store で一度サインアウト、その後もう一度サインインして試すとOKだった。

これ困ってる人多いんじゃないのかなぁ、バージョンアップの案内とは別に、事象から辿れるようにアナウンス出したほうが親切だと思う。

とりあえず使えるようになったので良かった。

Google Cloud Spanner

cloudplatform.googleblog.com

最近発表されたGoogle Cloudの新サービスSpanner。

SQLが使えるデータベースで、どうもCAP定理を打ち破ったらしい。

CAP定理自体は昔からよく言われるもので、すごくざっくり言うとDBのクラスタ

一貫性©/可用性(A)/分断耐性(P)

どれかを犠牲にしないといけないという話。

CAP定理 - Wikipedia

で、カタログスペックで見るとSpannerはすべてを満たしているようだ。

詳細の説明は

https://reearch.google.com/pubs/pub45855.html

のpdfで解説されているようだが、どうもGoogle Cloudで作り込まれたネットワークを利用することで

分断に対するリスクを減らしているということだと理解した。

たしかに分断を経験することはあまりないし、SDN(死語?)で見事なネットワーク冗長化をしていればなおさらだろう。

ただ簡単に真似できるものではない。予算が許すのであればぜひ使いたいと思う。

実際使ってみればいろいろと不満もあるのかもしれないが、このカタログスペックはもはや別次元。

なんとなく感じていたが、インフラは積極的にクラウドに載せたほうがいいかもしれない。

gaierror

pythonコードでgaierrorというのが出て、どうもエラー詳細から見ると名前解決のエラーのようだった。

 

gaiってなんぞ?と調べたところ、どうも getaddrinfo の頭をとってgaiらしい。

 

わかれば納得だが、非省略だとダメだったのかな。。。長いからダメということかな。