web微信

一、源代码地址:

二、总结:

  1.分析Http请求

    - 请求方式:get、post等等
    - URL:每个请求的url,固定部分和变换部分,一般动态的部分可能是在这个请求的前面的请求中有相关请求
    - Form Data  是data传值他默认的请求头是 application/x-www-form-urlencoded 一般用于form表单,后台request.POST.get(“name”)拿值
    - Request Payload  是json传值把整个大字典当成一个字符串传到后台,具体怎么传之前博客有写
    - 请求头: 这个是重点
      user-agent:当前用户的浏览器版本之类的信息,有的网站爬不了可能是因为这个,如知乎,知乎就是检测他
      Referer:而微信是搞了Referer的设置,这个东西是证明你是在我的网站上对我进行访问的我才同意你
      Content-Type : 能接收什么类型的请求头
      host : 把自己的域名写上就好了(ip可以试试)
      cookie : 这是关键

  2.代理:ip被封了就需要进行代理设置

时间: 2024-10-10 20:20:11

web微信的相关文章

在Web微信应用中使用博客园RSS以及Quartz.NET实现博客文章内容的定期推送功能

本篇随笔介绍在Web微信应用中使用博客园RSS以及Quartz.NET实现博客文章内容的定期推送功能,首先对Quartz.NET进行一个简单的介绍和代码分析,掌握对作业调度的处理,然后对博客园RSS内容的处理如何获取,并结合微信消息的群发接口进行内容的发送,从而构建了一个在Web应用中利用作业调度来进行消息发送的业务模型. Quartz.NET是一个开源的作业调度框架,非常适合在平时的工作中,定时轮询数据库同步,定时邮件通知,定时处理数据等. Quartz.NET允许开发人员根据时间间隔(或天)

实现手机扫描二维码页面登录,类似web微信-第一篇,业务分析

转自:http://www.cnblogs.com/fengyun99/p/3541249.html 关于XMPP组件的文章,先休息两天,好歹已经完整的写了一份. 这两天,先实现一套关于web微信扫描二维码页面登录的试验,因为这种模式在我们的很多业务场景里大有前途. 首先介绍一下web微信登录的过程 手机必须运行微信,并且合法登录 打开web微信的页面,展示一个二维码 用手机微信的扫描功能扫描该二维码 页面立即显示手机已扫描 手机显示是否确认登录,点击确认 页面登录 这个过程将传统的web登录转

WEB微信协议详注(待续)

当初写微信机器人也是为了个红包,虽然红包拿到了,过程还是蛮有意思的,下面给下详细说明. 微信入口主要有两个(wx和wx2),wx老号   wx2新号,我微信是老号了,为了测试方便采用的是老号入口. 1.入口抓包,获取uuid 开启浏览器F12功能,对https://wx.qq.com抓包,拿到我们需要的入口地址,获取uuid 参数说明:appid                  固定值 redirect_uri         固定值 fun                      固定值

Python 爬虫案例-web微信登陆与消息发送

首先回顾下网页微信登陆的一般流程 1.打开浏览器输入网址 2.使用手机微信扫码登陆 3.进入用户界面 1.打开浏览器输入网址 首先打开浏览器输入web微信网址,并进行监控: https://wx.qq.com/ 可以发现网页中包含了一个新的url,而这个url就是二维码的来源. https://login.weixin.qq.com/qrcode/wbfd1Z-a0g== 可以猜测一下获取url的一般网址就是https://login.weixin.qq.com/qrcode,而wbfd1Z-a

基于Flask 实现Web微信登陆

网页版微信登陆网址 https://login.wx.qq.com/ 获取微信登陆的二维码 在浏览器中访问登陆接口 https://login.wx.qq.com/ 我们查找二维码的图片可以看到 其中src为 https://login.weixin.qq.com/qrcode/Yd5dz5xUnw==" 而我们每次刷新都会生成一个新的二维码 多刷新几次我们会发现二维码中src最后面的qrcode/......值每次都会改变 ,索引肯定会有一些请求可以获取这些值 我们继续追踪发现下面的地址会返回

实现手机扫描二维码页面登录,类似web微信-第四篇,服务器端

转自:http://blog.csdn.net/otangba/article/details/8273952 终于到了服务器端,第三篇的手机客户端如果已经下载了的话,没有服务器是不能正常运行的. 服务器端要做得事很多,虽然逻辑不是很复杂,但是我们必须要分析清楚我们要做哪些事,请看下图: 通过这张图,我们看出,服务器端的接口一共有6个,分别处理: 手机客户端登录 首页 二维码图片流 long polling维持 接收手机客户端已扫描的通知 接收手机客户端已确认登录的通知 那么一个一个解决 首先是

web微信开发前期准备最新详细流程

一.申请配置测试公众号与配置本地服务器   1.打开浏览器,输入:http://mp.weixin.qq.com/debug/cgi-bin/sandbox?t=sandbox/login,微信扫码确认登录 2.进入到该页面,可以看到测试公众号的微信名,以及非常重要的appID和appsecret 3.填写服务器url,这个地址是要可以外网访问的,同时给微信服务器认证的,所以分两步走,一是先弄个外网可以访问的服务器地址,二是在该地址下放置微信官方要求的php文件 网上许多教程都是配置外网服务器,

实现手机扫描二维码页面登录,类似web微信-第二篇,关于二维码的自动生成

转自:http://www.cnblogs.com/fengyun99/p/3541251.html 接上一章,我们已经基本把业务逻辑分析清楚了 下面我们第一步,实现二维码的web动态生成. 页面的二维码包含的信息我在上一篇已经解释过,是一个页面的sessionID,这个sessionID主要是标示出哪个页面是哪个页面,例如你打开N个页面,必然每个页面的标示会不一样,只有你用手机扫描了某一个页面(page a)的二维码,将来响应操作的页面只能是page a. 实现二维码的类库非常多,如果你的平台

WEB微信协议详注(续)

先放一张效果图 以上的基础都是建立在正确同步心跳之上:呵呵,界面做的很丑哈,不过关键是功能实现了. 再次强调一次: 同步中所用的synckey 第一次所需的synckey是在微信初始化时返回的字串中,在开启同步心跳的时候第一次提交的synckey就是来源于此: 第一次同步心跳后返回的状态是2,这时候需要去提取一次新消息(即使没新消息也得去提取),这步关键是获取服务器 返回的synckey:如果有新消息,返回状态依然是2,但返回的synckey就是服务器上的synckey:如果没有新消息,返回 状