20190614
折腾精神
、学习能力
和逻辑能力
README.md
README.md
中生成(的README.html
,并改名为index.html)
README.md
中生成(的README.pdf
)
下面整理出crifan的折腾各种复杂问题的过程。
其中部分内容额外体现了需要一定的技术敏感度,才容易从发现问题细节,找到问题根源,最终解决问题。
期间各种折腾,遇到各种问题
最后才发现,其实涉及到了多个环境:
Python2
Python3
PySpider
中pipenv
最终解决问题的关键点之一是:
curl
为nss
,让pycurl
配合弄成nss
pip
安装出,版本匹配的,nss
的pycurl
python
和PySpider
的pipenv
都可以import pycurl
了最后不仅解决了问题,还整理出心得了:
期间的过程详见:
PySPider
的调试界面中的data的参数和postman中json参数不同
PySPider
中:J=%7B%22userId%22%3A%22...
Postman
中: {"J":"{\"userId\":\"1134723\",...
J=%7B%22userId%22%3A%22...
之类的数据中推断和猜测出:dict字典的json被额外encode了,是encoding编码后的字符串
PySpider
中self.crawl
的POST
的data
不被encode
编码
详见:
期间,要有足够的技术敏感度,才能及时想到可能的原因,然后才能证实和快速解决。
详见:
折腾期间,能想到利用:
网址是wordpress,然后再去搜wordpress中是否有和当前页面方面的标示,还真的巧了找到了current-menu-item
之后,才能通过css去控制current-menu-item,达到要显示的效果。
详见:
开始时最直接的反应,以为是以为缺少什么css呢,所以就去对比css,一点点的找,到底是哪些css不同而导致的异常
后来对比调试+细心发现,加上了is-active后,菜单可正常显示,说明不是缺少css
(重点:如果不是细心发现其实只是加上is-active即可,不知道后续还要在错误道路上,继续调试css多久)
而最开始想要调试,也没法调试,是无意间搜到网上帖子,得知是Enfold的avia-merged-styles-f39bxxxx773.css这种是合并后的
所以想到了,是不是可以有合并的参数设置,后来果然找到了
然后取消合并后,得到分别的独立的css(以及js)
从而后续可以单独看到js源码调试了
(重点:如果不是找到取消合并,则后续无法准确调试js到底执行了什么)
后来以为avia.js中的burger_wrap.click的代码执行有误呢,然后经过添加log日志,最终确定代码没问题
期间看到了加上了is-active,但是后来又没了
以为是jquery的AddClass失效了呢
而期间调试了N多次,始终有问题。
后来是第二天无意间重启了Mac的web server即mamp后,本地代码好像正常工作了
(重点:如果不是重启mamp,还不知道要继续浪费多少时间)
才调试发现
burger.addClass(“is-active”);
是正常执行的,是的确添加了is-active的class
而执行了后面的:
htmlEL.addClass(“av-burger-overlay-active”);
却导致菜单不正常显示的
就以为是:html的class中加了av-burger-overlay-active导致其他什么css生效,导致不正常显示呢
后来发现这个是正常现象
后来继续对比调试。以为是:
burger_wrap.click的 e.preventDefault();
没有执行到,导致burger_wrap.click被执行了2次
后来发现不是,而是通过Chrome调试期间,细心的注意到了:
前后的两个avia.js是enfodl父主题和子主题enfold-child两个独立的文件的相同函数
(重点:如果不是注意到是两个不同文件的avis.js中的burger_wrap.click,则解决问题的方向就偏了,还不知道要继续花多少时间才能回到正确方向上)
不是同一个avia.js中的两次执行相同的函数
从而确定是由于先后两次加载了都带burger_wrap.click的avai.js,而导致burger_wrap.click被执行了2次
最终经过Beyond Compare对比发现,enfold-child本身配置是相同的,而新旧两个Enfold主题,是版本不同,所以问题还是出在enfold主题。
然后自己通过间接的注释掉enfold-child的avia.js,才规避问题。
具体过程详见:
如果只是从问题的表面现象,很难想到根本原因。
幸好是从繁杂的信息中,找到了一个帖子,有个提示。
经过尝试最终发现是这个原因:
微软Azure,打着鼓励你用免费F0套餐,且免费的额度很多很多,但是实际上你使用了一点点后,就不给你继续使用,就告诉你超额了。然后你只能升级换成收费的套餐,才能正常继续使用。
详见:
关键点:
即使知道原因是:MongoDB中某些text中有特殊字符,导致显示小程序json解析出错,导致页面无法显示的问题
但是如果不懂这个是不可见的控制字符,以及如何去除,以及应该去掉哪些,那也是没法彻底的(去写代码,批量)解决问题的。
详见:
虽然最后没有把变砖的路由器救活,但是期间能够从网上繁杂的信息中,找到真正的串口的位置,以及最终买电烙铁和找到并买到合适的ttl的线,也算是不容易了。
详见:
nginx中配置了https的ssl证书,结果始终不起效果,打开https的地址 https://www.naturling.com/ 始终出现:
无法访问此网站,拒绝了我们的请求。 请尝试以下办法: 检查网络连接 检查代理服务器和防火墙
之类的错误
-》经过一点点问题的排除,包括但不限于:
cert和key的文件访问权限:从root改为nginx的www用户和组
ssl的各种参数配置,包括listen 80和listen,server_name,ssl_ciphers等等等等
-》最终发现:
nginx在listen 443同时如果加入了80,则http页面是可以打开的,有access的log的
-》但是https的访问,始终没有log
-》好像是https的请求,根本都没进入nginx
-》所以才怀疑是不是端口问题
-》但是阿里云的ECS的安全组中,已确保了添加了443端口了
(本身新建ECS时勾选了默认系统建了安全组就包括优先级110的443,担心有影响,又自己新建一个更高的优先级1的443的规则,且删除了系统的443规则)
但是还是不行。
-》最终是:(去CentOS中用firewalld去)添加防火墙规则,允许https的443端口入方向被访问
才使得https地址 https://www.naturling.com/ 能正常打开。
详见:
相关:
其中包括:
网上更多的人说安卓手机中安装Charles证书时,类型选择WLAN,结果被坑了,最后是换成少数人提到但是自己没试过的:VPN和应用,最后才正常安装证书,但是还不是安装到受信任凭据的系统中,而是用户中,以为没用,但是后来发现是有用的
-》规避了必须要root安卓手机的问题
-》也可以实现普通的https抓包解密未明文的效果了
最后把完整的操作步骤和中间遇到的大大小小的坑,都详细记录并整理到帖子里了,详见:
并且,后续又遇到:
部分https能抓包,但是其他特殊https无法抓包
期间也试了试其他路:找改安卓app的旧版本,希望万幸可以没有https的ssl pinning,最后失败
从:
Charles proxy fails on SSL Connect Method – Stack Overflow
以及其他一些帖子,基本上确定了此处无法破解的https是ssl pinning
而关于ssl pinning的办法,网上很多帖子,各种说法都很复杂,包括从apk逆向工程得到代码,再改动代码去破解的,所以放弃这些复杂的办法。
Android Security: SSL Pinning – Matthew Dolan – Medium
提到了之前Charles调试期间看到的,那个特殊的https是OkHttp,也知道旧版本貌似有bug
但是此处是最新的okhttp/3.10.0,没bug,所以也无法破解,也找不到其他相关的的办法。
后来终于找到一个相对解释的比较全的帖子,其中介绍了破解的办法:
Four Ways to Bypass Android SSL Verification and Certificate Pinning
但是却也没有给出有效且方便的办法。
而方便的办法,则是之前很多帖子中,断断续续提及的,包括这里也提到了:
如何对使用了ssl pinning的APP(如知乎)进行抓包? – 知乎
以及Android Security: SSL Pinning – Matthew Dolan – Medium 然后才知道,对于破解ssl pinning的办法:
通过
知道的:
但是需要去root手机才行
然后对于手上的手机想办法去root:
那么实在不行,考虑去购买个,便宜点的,比如1000以内中低端手机,应该都可以root的
然后就去研究便宜的可以root的安卓手机
结果发现,通过网上很多个root工具的支持机型,再去找手机,都找不到,因为都是旧型号手机,现在京东和天猫等都买不到了
再去单独从京东或天猫中找最新出的,1000以内的手机,再去找每个手机是否方便root,结果却又发现原本以为的常见的品牌,包括小胡,华为,中兴,Oppo,Vivo等等手机,却要么是之前可以root,但是最新都不支持了,比如华为的,之前可以申请解锁现在不支持了,要么是太贵了,总之现在都不论便宜和贵的,都很难买到一个手机,确保能顺利root的。
所以放弃。
后来的后来,突然想起来:去淘宝买个二手的手机吧,结果无意间发现,有人卖这种二手老手机且帮忙弄好root的手机,所以就去买二手的小米4,卖家帮忙先root好(其实自己也可以用工具去root,因为都是老的安卓系统,很多现有root工具都支持root的)
不过后来,突然想到:
貌似听某些人说,Charles的代理,也可以用安卓模拟器的
以及如何对使用了ssl pinning的APP(如知乎)进行抓包? – 知乎又提到了安卓模拟器,所以才想到另外这条路:
找个安卓模拟器,这样应该就容易解决root的问题了
最后经过尝试,在Mac中好用的,支持Wifi网络设置Charles的代理的,支持root权限的安卓模拟器是夜神安卓模拟器,
其中还有个细节:夜神模拟器的Wifi直接点击也无法设置代理,无意间(也包括之前自己用过Android,巧了有过类似精力)长按Wifi,才找到Wifi代理设置的
之后的路,就相对不那么难了,但是还有点小小曲折:
正常去夜神模拟器中安卓Charles的证书,
正常去模拟器中通过apk安装安卓的app
模拟器中安装xposed框架,结果最开始安装的夜神应用中心(按理说,系统自带的应用市场,肯定是最匹配,且效果最好的),安装的是5.1.1版本,结果后来证明是不兼容,不支持此夜神模拟器的
后来的后来,即使从官网或别处下载到正确的4.4的版本,去安装,也还是有问题
最后是自己意识到,可能需要先卸载已有的版本再安装才可以?
试了下先卸载5.1.1.的Xposed,再安装支持4.4的Xposed,终于可以正常安装了。
最后的最后,终于可以绕开ssl pinning,实现特殊的https也可以抓包解密看到明文了。
详见:
注:后来又去整理出独立的教程了:
虽然用gunicorn的gevent解决了Flask的app的单例问题,但是却发现另外还有2个线程,导致单例失效
而对于为何有这两个线程,其实开始是一点头绪是没有的。
而足够多的折腾精神和敏锐,让我找到了个思路:
可以从另外2个线程的log信息中,找到所对应的文件
这样就可以找到最开始打印log的文件
对于找到最终的线程的来源,应该会有帮助。
然后就找到了都是:
common/FlaskLogSingleton.py
log.info("LoggerSingleton inited, logSingleton=%s", logSingleton)
所打印出来的log:
[2018-08-30 13:28:35,272 INFO 26049 MainProcess 139969090553664 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f4d0add4080>
然后根据自己之前的代码,反推出,应该是别的模块中,调用了:
from common.FlaskLogSingleton import log
而触发上述的log的。
但是import log的地方也很多,并不容易找到是哪里的最开始引入的,以及也不容易因此就发现线程是如何创建的。
只是经验加上直觉,觉得最大的嫌疑是:
和Flask的app,感觉逻辑上属于并列的关系的celer
-》因为:
supervisor去管理和部署Flask的APP之外,还管理了celery:
[program:robotDemo_CeleryWorker] command=/root/.local/share/virtualenvs/robotDemo-dwdcgdaG/bin/celery worker -A resources.tasks.celery [program:robotDemo_CeleryBeat] command=/root/.local/share/virtualenvs/robotDemo-dwdcgdaG/bin/celery beat -A resources.tasks.celery --pidfile /var/run/celerybeat.pid -s /xxx/robotDemo/runtime/celerybeat-schedule
猜测其中的:
celery worker -A resources.tasks.celery
和
celery beat -A resources.tasks.celery
导致了另外两个的process的产生
接着后来再去找更多的日志信息,最后发现:
/celery-beat-robotDemo_CeleryBeat-stderr.log
[20180830 01:28:35 INFO 26049 MainProcess 139969090553664 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f4d0add4080>
和:
celery-worker-robotDemo_CeleryWorker-stderr.log
[20180830 01:28:35 INFO 26052 MainProcess 140308360062784 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f9c08e71048>
验证了之前的推测:
因为对应的log的第一条,就是我们之前找到的import log而输出了logSingleton的日志信息:
celery-beat-robotDemo_CeleryBeat-stderr.log
[20180830 01:28:35 INFO 26049 MainProcess 139969090553664 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f4d0add4080>
celery-worker-robotDemo_CeleryWorker-stderr.log
[20180830 01:28:35 INFO 26052 MainProcess 140308360062784 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f9c08e71048>
而其中:
就是最早发现的3个进程中的其中2个Process的ID的值:
[2018-08-30 13:28:37,129 INFO 26049 MainProcess 139969090553664 MainThread tasks.py:118 <module>] inited gMsTtsTokenSingleton=<resources.tasks.MsTtsTokenSingleton object at 0x7f4d0b32e128> [2018-08-30 13:28:38,078 INFO 26063 MainProcess 140140210039848 MainThread tasks.py:118 <module>] inited gMsTtsTokenSingleton=<resources.tasks.MsTtsTokenSingleton object at 0x7f74ea6d9710> [2018-08-30 13:28:39,545 INFO 26052 MainProcess 140308360062784 MainThread tasks.py:118 <module>] inited gMsTtsTokenSingleton=<resources.tasks.MsTtsTokenSingleton object at 0x7f9c09443908>
最终,而找到了:
除了supervisor+gunicorn去启动了Flask的app是单个Process之外:
supervisor还启动了Celery的worker和beat,这2个额外的Process
共3个线程,从而导致,虽然Flask的app中是单个Process,单例正常工作,
但是加上额外2个Process,导致单例失效:每个Process中初始化的实例都不同,无法保证单例的效果了。
总结:
此处之所以能够从大量的log日志中,最终分析找到产品额外2个进程的原因,主要是靠:
先是要了解自己写的代码的逻辑关系:此处涉及到近10个文件,以及好几个配置文件
其次要足够仔细和认真:要能否思路活跃,看到相关的日志信息后,能够实现基本的逻辑推理
一定的敏感度:能否在推理的基础上,思维活跃,偶尔联想到,猜到,可能和其他哪些模块有关系
最终通过 熟悉代码+足够认真+思维敏感 而找到问题原因并解决。
详见:
先后尝试了可算达到上百个点了。
相比而言,之前的折腾时遇到比较多的,也就三五十个尝试的点,也就把问题搞定了。
期间有几次都打算放弃了,但是后来还是坚持继续找问题原因,最终功夫不负有心人,终于搞定了:
详见:
期间,也基本是,都差不多放弃了
因为实在找不到是什么原因
而且网上也没有类似的参考资料
其他找到的资料,也没太大参考价值
最后,还是自己巧了,试了试java的classpath改为分好分隔后,虽然不行,但是想到了加上引号试试,结果才搞定的。
然后再回头找原因,才找到了该问题的根据原因并解决的。
详见:
详见:
在折腾:
期间,就在迷茫的时候 能想到去试试
rq worker
最终明白flask-rq2
是需要rq worker
的后台服务才能工作的
antd pro中,前端页面中列表的loading很慢:
开始就知道后端Django有一次性返回所有页面的数据,而不是当前页面数据的问题
但是发现好像是antd pro的loading的绑定有问题,后来发现不是
又以为和antd pro的yield 或call有问题,发现也不是
又以为是js的fetch有问题,发现早就返回response了
又以为是fetch后的response去json()数据量大时,很耗时
结果去花精力解决了后端Django只返回当前页数据后,依旧很慢,发现不是json()慢
再后来是,antd pro的reactjs前端的js的console的log 和 Django的后端的api请求 联合对此,最终发现:
Django后端的代码耗时太长,很多的mysql的查询和其他操作,导致很慢
具体点就是:
所以加起来要8,9秒。
所以需要去优化原有的处理逻辑:
详见:
之前类似错误,简单的就已通过:
就解决了。
而此处的问题,是同事另外一台Mac。
折腾和尝试了各种思路和方向,都没有结果,详见:
而此处真正对解决问题的有帮助的点是:
除了之前已有的类似的经历,还要加上:
之前经历过2种类似和相关问题:
【已解决】Mac中编译安装pycurl失败:error: command ‘gcc’ failed with exit status 1
还要加上足够细心和敏感才能注意到:
【已解决】Mac中编译安装pycurl失败:error: command ‘gcc’ failed with exit status 1
中是用的LibreSSL
以及也注意到了旧Mac中用的是OpenSSL
由此才能想到可能是openssl内部调用的库,不同:
以及又(有想要去了解新技术的动力,所以才)去找了相关的解释:
然后看到提到了是10.11的OS X之后也换用了LibreSSL
所以才想到这个点,可能是解决问题的方向
->最终经过升级Mac系统到最新版本Mojave而真正解决问题。
总结起来就是说:
能解决此问题有很多必要因素:
第一次折腾IP代理池时,对于各种相关概念不了解,连想要选购合适产品都不容易。
但是通过一些IP代理池服务商的网站产品的简单介绍:
自己悟出和理解出相关含义和区别,并整理出来了:
然后就可以购买和使用合适自己需求的代理了:
比如在 汽车销售领域内整理客户和线索的逻辑和流程时把已有的:
潜客和线索的关系和操作逻辑:
稍加整理,变为逻辑更加清楚的: