最近笔者的项目需要找到一种方法能自动将Python爬虫产生的一些结果用告警的信息的方式发送到手机上，以往我们用来发送告警的方式往往是短信或者邮件，但是这两种方式要么不够灵活要么实时性不够。现在越来越多的互联网应用选择用微信作为平台发送告警信息，这种方式的前提就是你的应用需要能够访问到微信的服务器。
根据笔者的了解，目前集成微信告警主要有两种方式：
顾名思义，虽然也是调用微信的API实现发送信息，但是这种方式需要使用个人账号扫描登录以后脚本才能运行，另外从接受告警的形式上看起来也就像是跟一个人在聊天。当前已经有很多热心的大神将微信的接口封装成了更加易于调用的接口SDK，如wxpy和wechat sender可以大大简化接口调用的复杂度，感兴趣的读者可以自行研究，上述两个项目的文档已经写的非常详细了
最近的项目在做一些数据方面的集成，五花八门的系统对应的接口更是千奇百怪，数据集成的过程总结成八个字就是：逢山开路，遇水架桥。
恰好这两天碰到一个问题，我们要集成的WEB系统没有提供专门的数据集成接口，没有API可以调，数据库更是不让访问，万般无奈之下，我在想是否可以用python自动爬取页面。web页面有SSO，用的应该是开源的CAS框架，并且后面的页面全都是由动态JS、AJAX异步加载进去的，这显然不像普通的静态页面那样直接用Scrapy上去就是一顿干，要完美的模拟登陆动作并且还要爬取后面的动态内容，对页面结构和爬取内容的分析是必不可少的。
Kafka因为具有优秀的并发读写性能在大数据收集传输过程中有的非常重要的作用。近期项目计划将Kafka作为数据建模分析的总线使用，但是因为项目的特殊性需求，我们在两个不同的地理位置上部署了两套Kafka队列，并且要求其中一套能把数据传递到另一套的指定队列，说简单点就是需要从一个Kafka队列里读数据，然后写到另一个Kafka队列里，读写Kafka队列的工具有很多，相比Apache Flume我们更倾向于Logstash。本文简单介绍一下何如基于Docker容器配置Logstash集成Kafka。
假设有两个Kafka的Topic：
实现用Logstash读/写队列实验。
因为工作的原因，近期笔者开始持续关注一些安全咨询网站，一来是多了解业界安全咨询提升自身安全知识，二来也是需要从各类安全网站上收集漏洞情报。
作为安全情报领域的新手，面对大量的安全咨询，多少还是会感觉无从下手力不从心。周末闲来无事，突发奇想，如果搞个爬虫，先把网络安全类文章爬下来，然后用机器学习先对文章进行分析，自动提取文章主成分关键词，然后再根据实际需求有选择的阅读相关文章，岂不是可以节省很多时间。
如果能提取文章的关键词，还可以根据近期文章的关键词汇总了解总体的安全态势和舆情，感觉挺靠谱。
如前文所述，思路其实很简单：
Splunk是业界赫赫有名的数据分析工具，比较擅长BI和安全日志分析，我司很多部门都有购买其产品和服务。最近有个需求要把Splunk和分布式消息队列Kafka做个集成，Splunk官方提供的一个Kafka的插件，可以很容易的做到与开源Kafka集成，本文简单描述一下集成的配置方法。
这里假设你的环境里已经搭建好了Splunk和Kafka（Splunk搭建请参考，Kafka搭建请参考）。
Splunk Add-on for kafka
支持三种输入
本文基于Docker搭建一套单节点的Kafka消息队列，Kafka依赖Zookeeper为其管理集群信息，虽然本例不涉及集群，但是该有的组件都还是会有，典型的kafka分布式架构如下图所示。本例搭建的示例包含Zookeeper + Kafka + Kafka-manger
本文基于Splunk Forwarder自动收集Windows日志，将日志发送到Splunk做统一收集，并建立简单的图标分析，实时监控Windows系统日志。
Splunk官方提供60天，500M的免费试用期，本文基于官方的免费Docker镜像搭建实验环境，安装过程非常简答，这里不再赘述，可以参考Splunk Docker文档相关内容搭建简单的Splunk环境。
本文简要介绍一下开源Java混淆编译工具ProGuard的实际应用案例。我们知道某些情况下软件的作者需要保护软件本身不被使用者反编译，或者给对方反编译制造一定的障碍，为了达到这个目的人们可以有很多不同的做法，比如在编译的过程中把一些变量名替换成无意义的abcd或者将类名方法打散等等，制造一些混乱让反编译的人很难读懂你的逻辑；还有一种是对java编译后的class文件加密，然后用自定义的classLoader去解密并加载到JVM，这种方式有个问题，一旦对方拿到你这个自定义的ClassLoader那么保密也就不存在了。相信类似的技术手段还有很多，用ProGuard对Spring Boot的应用做混淆处理
本文简要总结一下如果使用Spring Security OAuth和Spring Boot来实现SSO，文末有样例代码。不了解OAuth2.0协议的同学请参考《OAuth2.0协议原理详解》
整个工程包括三个独立的应用，一个认证服务和两个客户端应用，结构非常简单。当一个用户访问客户端应用中被防护的API时，系统会被自动重定向到认证服务，之后我们使用OAuth2.0的Authorization code授权方式来实现认证授权。
OAuth 2.0 是目前比较流行的做法，它率先被Google, Yahoo, Microsoft, Facebook等使用。之所以标注为 2.0，是因为最初有一个1.0协议，但这个1.0协议被弄得太复杂，易用性差，所以没有得到普及。2.0是一个新的设计，协议简单清晰，但它并不兼容1.0，可以说与1.0没什么关系。所以，我就只介绍2.0。
从引言部分的描述我们可以看出，OAuth的参与实体至少有如下4个：