testcafeにて、QRコードを読み込んでiOSを起動するまでの、道のり。

#はじめに
testcafeにて、QRコードを読み込んでiOSを起動するまでの、道のり。

# 最終更新日
2022年1月17日

# 環境の情報
OS
Ubuntu20.04


# 注意
最新の状態を確認して下さい。

# 公式はこちら
https://testcafe.io/
https://testcafe.io/documentation/402631/why-testcafe

#参考さま
https://github.com/DevExpress/testcafe-hammerhead
http://var.blog.jp/archives/82577944.html
https://dzone.com/articles/testcafe-e2e-testing-tool
https://bufferings.hatenablog.com/entry/2020/07/18/181234
http://var.blog.jp/archives/82577944.html


#状況

### iOSの状況

testcafeを入れ、iOSでQRを読み取ろうとしたころであった。
思わぬところで詰まってしまった。

```
testcafe remote spautomation.js --qr-code
```

![Screenshot from 2022-01-17 21-48-04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/148394/005c0b9e-e637-7286-6065-a2ccc3c6a0a4.png)




しーん

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f3134383339342f35643861633431622d383031382d383165392d353934612d3962333835303463366462612e706e67.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/148394/f9eab97b-8b1a-7acb-6350-54bd067bcc9e.png)

開けません、とiOSは静かに言うだけであった。
無口なiOSさんなのであった。
あんた！なんか喋りなさいよ！


### PCの状況

PCの方はこのようになっていた。

```
Connect URL: http://192.XXX.XX.XX:XXXXX/browser/connect
↓
クリックする
↓
http://192.XXX.XX.XX:XXXXX/browser/idle/AaAAAaA（みたいなURLになる）
```

# 調査
よくわからないので調べてみた。

https://testcafe.io/documentation/402631/why-testcafe

```
Page Proxying
You may notice that when you run TestCafe, the URL in the browser's address bar does not match that of your website. This happens because TestCafe runs an under-the-hood reverse proxy.
The testcafe-hammerhead

proxy intercepts browser requests and injects automation scripts into the requested pages. When the proxy receives data, it changes all the URLs on the resource so that they point to the proxy. This means that neither the client-side code nor other resources in use can tell that the page has been modified. To conceal automation scripts from the rest of the page code, TestCafe also intercepts some of the requests to the browser API.
The proxying mechanism ensures that the page appears to be hosted at the original URL even to the test code.

ページプロキシ
TestCafeを実行すると、ブラウザのアドレスバーのURLがWebサイトのURLと一致しないことに気付くかもしれません。 これは、TestCafeが内部のリバースプロキシを実行しているために発生します。
テストカフェ-シュモクザメ

プロキシはブラウザのリクエストをインターセプトし、リクエストされたページに自動化スクリプトを挿入します。 プロキシがデータを受信すると、プロキシを指すようにリソース上のすべてのURLを変更します。 これは、クライアント側のコードも使用中の他のリソースも、ページが変更されたことを認識できないことを意味します。 残りのページコードから自動化スクリプトを隠すために、TestCafeはブラウザAPIへのリクエストの一部もインターセプトします。
プロキシメカニズムにより、テストコードに対しても、ページが元のURLでホストされているように見えます。 
```


どうやら、testcafe-hammerheadという、URL書き換える、プロキシ?を使っている？よう。
けどそれが上手く機能していないんじゃあないかと。
なんか、ネットワークのやりとりを邪魔するやつがいるのでは？と、ふと思ったところ。


# 解決策

節穴。

```
$ sudo /etc/init.d/firewalld status
[sudo] user のパスワード: 
● firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-01-14 11:24:45 JST; 5h 32min ago
       Docs: man:firewalld(1)
   Main PID: 1028 (firewalld)
      Tasks: 2 (limit: 18841)
     Memory: 30.9M
     CGroup: /system.slice/firewalld.service
             └─1028 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid
```


＿人人人人人人人人人人人人人人＿
＞　動いちゃってるんだよね〜　＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

＿人人人人人人人人人人人人人人人人人＿
＞　ファイヤーウォールなんだよね〜　＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

```
$ sudo /etc/init.d/firewalld stop
Stopping firewalld (via systemctl): firewalld.service.
```

＿人人人人人人人人人人＿
＞　止めちゃうよね〜　＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y￣


```
$ sudo /etc/init.d/firewalld status
● firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Fri 2022-01-14 16:57:37 JST; 3s ago
       Docs: man:firewalld(1)
    Process: 1028 ExecStart=/usr/sbin/firewalld --nofork --nopid (code=exited, status=0/SUCCESS)
   Main PID: 1028 (code=exited, status=0/SUCCESS)
```
＿人人人人人人人人人＿
＞　止まったよね〜　＜
￣Y^Y^Y^Y^Y^Y^Y^Y￣


#そして
iOSで、読み込んでtestcafe動くようになった！やったね！