[解決済み] Nature Remoは一度メールアドレスを認証させてしまうと変更時にめっちゃくちゃめんどくさい。

表題の通り、というかガジェット系は不具合あっても割とイライラせずに使用するタイプだと思ってるのですが、これはさすがに改善要求したいレベルで仕様がひどかったです。散々発売延期してコレかよ…。

2018/05/29 追記

2018/3/13のアップデートでログアウトとメールアドレスの編集ができるようになったため、以下の問題は解決可能です。

あらまし

Nature RemoとGoogle Home miniを買ったので、IFTTTで連携しようと思いました。nexus5xでアプリをインストールし、メールアドレスAでRemoのアカウント登録を実施し、セットアップ→家電の登録まで済ませました。
次にIFTTTでGoogle Assistantを認証し、Nature Remoの連携も実施しました。これで晴れて音声で家電が操作できるようになりました。やったぜ。ここまではめっちゃくちゃ簡単でしたし、コーディング無しでここまでのことができるのはかなりすごいです。

問題となる操作

ここまでセットアップしたところで、どうしても他のメールアドレスを使用してRemoのアプリ、及びRemoを使用しなければならない事情が発生しました。メールアドレスAではなく、メールアドレスBを使用して最初から全部やり直します。
とりあえずNature Remoの背面ボタンを押してハードリセットしました。壁に貼ってるので、リセットボタンは背面ではなく側面につけてほしかったです。
なお、以降に書いた操作はnexus5x 1台で行っています。

何が問題になるか

  • Nature Remoのアプリにサインアウトの方法がない。(少なくともAndroidアプリにはない)

単純にアプリをアンインストールするだけだと設定値が残存するため、アプリデータを削除してからアンインストールしないとログアウトできません。というか登録済みのアカウントってどこで削除すればいいんでしょうか…。

  • IFTTTとConnectする時に、Connect先のRemoアカウントが古い方になる

  • OAuth認証時に、認証先のRemoアカウントがわからない

IFTTTとRemoの連携をIFTTTのServicesから削除した後、RemoにConnectしなおす場合、ブラウザでOAuth認証するアカウントの対象が古いメールアドレスになります。TwitterのようにOAuth認証画面で認証先のアカウントを確認+変更できれば良いのですが、アカウントがどれなのかもわからないし、認証画面でログアウトもできないので、仕方なくブラウザのキャッシュを全消しして対処しました。
これがかなりクソで、Connect後にServicesを確認しないとどのRemoアカウントと連携してるのかわからないので、古い方のRemoアカウントと連携しているのに気づかず、いつまでたってもRemo側の設定値がIFTTTから読めなくてめっちゃくちゃイライラしました。30分くらいハマった時点でやっと気づいたのですが、ユーザのせいって言われると納得行かない仕様だと思いました。

想定していない操作だったのかもしれませんが、メールアドレス変わったときとかどうすればいいのかわからないし、改善してほしいです。

上記仕様とアプリ自体が初期のPokemon GOレベルで不安定なのを除けばRemo自体は便利です。エアコンも簡単に制御できますし、IRKitで問題だったLEDもまぶしくないし、早くREST API公開してほしいなぁと思います。公開されましたね。

tag.retrorocket.biz(はっしゅたんぐら。)のデータが飛びました。

物理的に壊れたのとバックアップも取ってなかったので復旧できません。ほんとすいません。
tag.retrorocket.biz(はっしゅたんぐら。)については利用者が片手で数えるくらいしかいないので、Raspberry Pi 3で運用していたのですが、引っ越しの時にSDカードがぶっ壊れたようでサルベージすらできませんでした。
とりあえずサービス自体はさくらVPSに移行しましたが、IFTTTで同じことができるはず(実際にできるかどうかは試してません)なので、今後はIFTTTの使用をおすすめします。

【雑感】Fiddlerを使ってHuawei nova liteのパケットをキャプチャした。

結構前からnova liteがBaiduと通信してると話題なのですが、2chのスレを見てもほぼまともな情報が得られないのと、ぐぐっても結局通信内容が不明のままだったので、諦めて自分でキャプチャすることにしました。
飽くまで私の持ってる端末・環境での観測結果なので、ご自身の端末がどのような通信をしているのか知りたい方は、ご自身でパケットキャプチャされることをおすすめします。
Wiresharkを使っても良かったのですが、手元にFiddlerの入ってるマシンしかなかったのでFiddlerを使いました。Androidでのパケットキャプチャ用の設定は以下の記事が分かりやすかったです。
Android端末上のHTTP/HTTPS(SSL)通信内容を傍受・解析する方法

観測対象

Huawei nova lite/PRA-LX2C635B160
(現在地が中国以外だと通信しないという話らしいので、情報を載せておくと、)位置情報設定は「高精度」に設定してあります。高精度じゃないとPokemon GOできなくなるので。

観測方法

1時間程度、スリープしないようにして端末を放置。

結果

1時間内で3回 www.baidu.com 宛にGETでアクセスをしていました。(HTTP宛で、クエリパラメータはなしです。)
あと、端末電源ON時に必ずbaiduと通信する、という話も見かけたので何度か電源ON時のパケットもキャプチャしましたが、いずれもbaidu宛の通信は見つかりませんでした。

以下リクエストのキャプチャ結果(3回とも全部同じでした)

GET http://www.baidu.com HTTP/1.1
Charsert: UTF-8
Accept-Charset: utf-8
Content-Type: application/x-www-form-urlencoded
contentType: utf-8
User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; PRA-LX2 Build/HUAWEIPRA-LX2)
Host: www.baidu.com
Connection: Keep-Alive
Accept-Encoding: gzip

ちなみに肝心のレスポンスですが、Fiddlerは504を返してきました。うーん…。

[Fiddler] ReadResponse() failed: The server did not return a response for this request. Server returned 0 bytes.

名前解決用にリクエスト飛ばしてるのかもしれないですが、情報がなさすぎて憶測の域を出ませんね。
(24時間くらいがっつりモニタリングしたら何かわかるかもしれないですが、)1時間程度ではよくわかりません、という感想です。
Baiduと通信してるのは確実なことがわかったので、購入はあんまりおすすめできません。

追記(2017/08/20)

Fiddlerのようにローカルプロキシを挟むとローカルプロキシが解釈できないレスポンスがエラーになるので、Wiresharkを使おうとしたのですが、どう頑張っても家のWi-Fiでモニターモードが使用できなかったため、諦めてtPacketCaptureを使用してキャプチャしました。

3時間キャプチャして10回baidu宛の通信を確認しました。以下リクエストです。10回とも内容は全部同じでした。

# 103.235.46.39 宛に通信。
Hypertext Transfer Protocol
    GET / HTTP/1.1\r\n
    Charsert: UTF-8\r\n
    Accept-Charset: utf-8\r\n
    Content-Type: application/x-www-form-urlencoded\r\n
    contentType: utf-8\r\n
    User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; PRA-LX2 Build/HUAWEIPRA-LX2)\r\n
    Host: www.baidu.com\r\n
    Connection: Keep-Alive\r\n
    Accept-Encoding: gzip\r\n
    \r\n
    [Full request URI: http://www.baidu.com/]
    [HTTP request 1/1]
    [Response in frame: 471]

以下レスポンス。値がユニークっぽそうな箇所は念のため伏せました。

Hypertext Transfer Protocol
    HTTP/1.1 302 Found\r\n
    Cache-Control: no-cache\r\n
    Connection: Keep-Alive\r\n
    Content-Type: text/html;charset=utf-8\r\n
    Date: Sun, 20 Aug 2017 14:29:54 GMT\r\n
    Location: https://m.baidu.com/?from=844b&vit=fps\r\n
    P3p: CP=" OTI DSP COR IVA OUR IND COM "\r\n
    Server: apache\r\n
    Set-Cookie: BAIDUID=C438EAAB0EFE52A771xxxxx:FG=1; max-age=31536000; expires=Mon, 20-Aug-18 14:29:54 GMT; domain=.baidu.com; path=/; version=1\r\n
     [truncated]Set-Cookie: H_WISE_SIDS=118416_114550_117615_118309_117044_114744_118507_100100_118270_118057_xxx...
    Set-Cookie: BDSVRTM=42; path=/\r\n
    Tracecode: 1794964229xxxxxx\r\n
    Tracecode: 1794926598xxxxxx\r\n
    Traceid: 1503239394xxxxxxxxxx\r\n
    Content-Length: 0\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.189395000 seconds]
    [Request in frame: 469]

似たような通信がないかぐぐると2chのg07スレが見つかりました。
goo g07 Part3 [無断転載禁止]©2ch.net

13 SIM無しさん (オイコラミネオ MMf6-0Bqe)2017/03/29(水) 16:32:10.03ID:8pI43FAvM
GPSの関係でBidouにアクセスが発生する端末が
あると聞いたが、広告騒ぎとは関係なさそうだけどこの通信が必要な理由はなんだろう

Source 103.235.46.39  (BAIDU-HK)
Dustination (略)

HTTP/1.1 302 Found
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 0
Content-Type: text/html;charset=utf-8
Date: Wed, 29 Mar 2017 05:57:17 GMT
Location: https://m.baidu.com/?from=844b&vit=fps
P3p: CP=” OTI DSP COR IVA OUR IND COM ”
Server: apache
Set-Cookie: BAIDUID=(略):FG=1; max-age=31536000; expires=Thu, 29-Mar-18 05:57:17 GMT; domain=.baidu.com; path=/; version=1
Set-Cookie: H_WISE_SIDS=102569_108266_100043_102435_103300_111882_112106_107313_114130_115245_115110_115055_115244_115044_114797_114513_114998_114330_114535_115031_114276_110085; path=/; domain=.baidu.com
Set-Cookie: BDSVRTM=81; path=/

gooのg07ってcovia製ですよね。あるぇー…。
これ以上調べても新しい情報が見つからなさそうなので私は調査を降ります…。まさに「何の成果も!!得られませんでした!!」って感じですね。何のために通信してるのか全くわからん。

追記(2017/09/17)

Huawei nova lite/PRA-LX2C635B170にアップデートしたところ、6時間観測して1度もbaiduとの通信を検出しませんでした。位置情報をOFFにしても検出しなかったのでかなり謎いです。
しれっとバグを直したとか、通信しないようにしたとかそんな感じでしょうか。如何せん公式に発表もないですし、怪しいことには変わりないので、購入はあんまりおすすめできません。BlueBorneのパッチもいつくるかわからないし…

retrorocket.bizのSSL証明書を再発行しました。

SSLサーバ証明書再発行のお願い – さくらのサポート情報
retrorocket.bizも対象なので再発行しました。これから3年間分無料とはありがたいです…。期限ギリギリまで発行を粘ってちょっとでも証明書の有効期限を伸ばそうかと思いましたが、引き伸ばしてるうちに対応を忘れてしまいそうなのでやめました。
nginxの場合、ssl_certificateに中間証明書を設定しないとサーバから中間証明書が送付されないのですが、完っ全に失念してまして30分くらい本気で悩みました。次の移行時にまた忘れそうですね。

再発行に至った背景は以下の記事がとてもわかりやすいです。
Symantecが再びGoogleの信頼を失った件についてのメモ – Technically, technophobic.
個人的に「シマンテックの言い分が大変うんこである」以外の感想はないです。ブラウザベンダー側が拒否らないと改善されないのもひどい。でもお金払っちゃったから使います。

retrorocket.bizのSSL証明書をラピッドSSLに移行しました。
去年くらいにラピッドSSLに移行したものだと思っていたら2年前でビビりました。

とりあえずOCSP Responseが返ってくるかは確認しました。

$ openssl s_client -connect retrorocket.biz:443 -status -servername retrorocket.biz < /dev/null | head
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA
verify return:1
depth=0 CN = retrorocket.biz
verify return:1
CONNECTED(00000003)
OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 04F2100E425F1B9605707A171B87FDED0C1A9B92
    Produced At: Jul 20 09:29:11 2017 GMT
    Responses:
DONE

問題ないですね。

【未解決→解決】WPtouch Mobile Pluginが適用されたモバイルページでContact Form 7が動作しない。

未解決です。このサーバでしか起こらない問題かどうかすらもわかってません…。
Contact Form 7のv4.8とWPtouch Mobile Pluginのv4.3.18を導入している環境で、かつモバイルページからContact Form 7を使用して問い合わせを送信した場合、メールが送信されません。
WordPressのバージョンは4.8です。

最初nginxのキャッシュフラグの設定がおかしいかと思ったのですが、curlコマンドでPOSTした場合は正しく問い合わせが送信できるためWPtouchとの組み合わせが悪いと判断しました。(curlでUAをモバイル系にすると送信されないが、適当な文字列にすると送信できる)

php-fpmのログにもnginxのログにも何も出てないし、POSTを送信すると200OKしか返ってこないのでデバッグが面倒です。いま適用しているテーマはありがたいことにレスポンシブデザインなので、とりあえずWPtouchを無効にしました。

この現象がいつから起こっていたか把握できないため、過去スマホ・タブレット経由でcontactからお問い合わせを送信された方につきましては、お手数ですが再度送信をお願いいたします。すみません…。

追記(2017/08/08)

普通にContact Form 7用のjsがWPtouch用のテンプレートで読み込まれていないからでした。仕方ないので、footerに以下のコードを挿入して解消しました。
js無いと動かないんですね。そりゃそうか。

<script type='text/javascript'>
/* <![CDATA[ */
var wpcf7 = {"apiSettings":{"root":"https:\/\/retrorocket.biz\/wp-json\/contact-form-7\/v1","namespace":"contact-form-7\/v1"},"recaptcha":{"messages":{"empty":"\u3042\u306a\u305f\u304c\u30ed\u30dc\u30c3\u30c8\u3067\u306f\u306a\u3044\u3053\u3068\u3092\u8a3c\u660e\u3057\u3066\u304f\u3060\u3055\u3044\u3002"}}};
/* ]]> */
</script>
<script type='text/javascript' src='https://retrorocket.biz/wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=4.8.1'></script>