After I have installed Xcode6/iOS Simulator(iOS8), Charles seems can't capture any requests from iOS Simulator.
and Proxy-> Access Control Setting is clean. All Charles settings weren't be modified after upgraded Xcode6
Anybody has the same trouble ?
I get this problem because I use a proxy in my wifi connection to go though the FXK GFW. In this situation, some requests won't go through charles.
You can check this out.
Related
I've been trying to get my iOS device to show me network traffic on Charles proxy but I haven't found any solution yet.
The code presented in here is the closest thing I have found that works:
https://medium.com/hoursofoperation/use-charles-proxy-to-debug-network-requests-in-flutter-apps-2f2083275cad
However, this only shows traffic in Charles if the project is run on simulator.
I don't know why simulator works and Device doesn't.
I tried changing the ip address of the proxy from code in the above blog to the ip address of the phone, to my computer, and to the proxy server.
Nothing works and all calls just flat out fail.
I know my phone can go through Charles normally, because other web calls still happen.
So what do I need to change for Flutter to work on my device?
I am going to catch tcp packages by using Charles when developing IOS app, but it failed to catch anything when the app running in the simulator.However everything works well when I using safari or other apps both in or out of the simulator.So it seems that only my app in the simulator has this problem.
I have tried this https://www.charlesproxy.com/documentation/faqs/ssl-proxying-with-ios-9/ ,but it didn't work.
Please do me a favor. Thanks
Well...It seems that Charles is unable to capture tcp package, it is designed to capture http/https traffic instead...
Wireshark may be a good choice BTW.
I had been using Charles to proxy traffic from my iPad (iOS 9.0.1) on Chrome and Safari for some time but for some reason it has stopped working.
I recently updated Charles to the latest version and regenerated the SSL certificate (as it warns you must be done) so am now running version 3.11.2.
Safari works just fine - it seems to recognise the certificate. But with Chrome pulling the option to navigate to a link even if the connection is not private in a recent update to their browser(s), I am left unable to proxy anything.
Interestingly, using Chrome on my Samsung Galaxy S5 still allows for proxying through Charles. The Samsung and iPad are both using the same proxy, and same cert, so I know it's not a config issue. It's something to do with Chrome on iOS.
Has anyone figured out a way around this?
To answer it in short: Chrome on iOS ignores root CA certificate.
You could find more information here (the latest update said that it was fixed on M-48, which is using WKWebView on iOS 9+).
Could somebody help me for the below issue:
I am not able to connect to work light development server from iOS device(work light 6.2)
It works fine in worklight emulator and Xcode simulator.
Do I need to do any change in the device settings to connect?
Thanks.
Would be better had you provided any errors you see in Xcode Console or in the Details view in the app, available when the application fails to connect to the Worklight Server.
Anyway, the usual culprit would be if the device is not connected to the same network as the development server. Make sure both are connected to the same network.
The problem i have is really anoying. Basically if I put "https://a.domainX.com" in Safari on an iPad 3, I get a message that the server did not respond. But if I put the same URL on Opera in the tablet, the page get's displayed correctly.
Also if I put a PROXY between the iPad and the server, the page get's displayed correctly. My current guess is that the Safari browser cannot resolve the domain correctly or there is some problem with the SSL certificate, but only on Safari.
Chrome has the same behavior that Safari, and I presume sinche both browsers are implemented based on WebKIT.
Finally, I did monitor the Safari browser from a Macbook, but there is no information there that could be usefull to debug this problem.
Any tips or suggestions would be appreciated.
PD: English is not my native language, so sorry for any mistakes :)
Finally we where able to debug the problem and we had to use a network sniffer to follow the HTTPS connection flow. The problem was that at some point after the latest iOS upgrade the iPad did not work well with the server side encryption algorithms we had defined, and the HTTPS negotiation didn't go all the way through.
Changing the server side to newer algorithms (and disabling the older ones) did the trick and after that all is working ok.
It was quite difficult to manage this, but we where able to replicate this solution:
http://www.cardinalpeak.com/blog/sniffing-ipad-traffic/
Basically it's about putting a computer between the network and the iPad to sniff the network packets. We didn't use a computer tho, we just connected to the communications switch to see the traffic and redirected the port traffic to the one where we had Wireshark installed (http://www.wireshark.org/), but I guess this is not common solution for everyone.
I hope this helps if anyone has the same or similar problem.