相信很多人是喜欢用印象笔记的，比如ghostsf 哈哈！
那么也相信很多人发现印象笔记客户端会出现同步失败的情况，同步按钮有红色感叹号，然后每次同步都会提示可能服务器出现了什么问题，- -。
网上经常出现的方案就是：印象笔记windows客户端同步失败怎么解决？
1、重启，升级，清空废纸篓，备份删
2、重建数据库：重新下载本地笔记文件
当然如果对你有用，就不用往下看了。
其实还有一个原因就是印象笔记对同步设备的数量限制。
一般免费账号会被限制只能使用两台设备。
我们在这里可以看到。
如果超过了同一免费账号绑定了超过两台设备，这时候就会出现同步失败的情况。
可以去到我的账户页面的设备管理页面进行撤销：
https://app.yinxiang.com/Devices.action
撤销访问掉一台设备即可。
By the way，ghostsf在写这篇博文的时候，发现我的账户变为高级账户了，也是莫名其妙（真的什么都没干啊）。
虽然2017年3月5日到期，哈哈。不知道是不是印象笔记抽风了。
RT
Caused by: java.lang.ArrayIndexOutOfBoundsException: 21
at oracle.jdbc.driver.OracleSql.computeBasicInfo(OracleSql.java:950)
oracle ojdbc6的驱动包是存在bug的。
具体看Raimonds Simanovskis的分析：
In Oracle Metalink (Oracle's support site - Note ID 736273.1) I found that this is a bug in JDBC adapter (version 10.2.0.0.0 to 11.1.0.7.0) that when you call preparedStatement with more than 7 positional parameters then JDBC will throw this error.
If you have access to Oracle Metalink then one option is to go there and download mentioned patch.
The other solution is workaround - use named parameters instead of positional parameters:
INSERT INTO rule_definitions(RULE_DEFINITION_SYS,rule_definition_type,
rule_name,rule_text,rule_comment,rule_message,rule_condition,rule_active,
rule_type,current_value,last_modified_by,last_modified_dttm,
rule_category_sys,recheck_unit,recheck_period,trackable)
VALUES(RULE_DEFINITIONS_SEQ.NEXTVAL,:rule_definition_type,
:rule_name,:rule_text,:rule_comment,:rule_message,:rule_condition,:rule_active,
:rule_type,:current_value,:last_modified_by,:last_modified_dttm,
:rule_category_sys,:recheck_unit,:recheck_period,:trackable)
and then use
preparedStatement.setStringAtName("rule_definition_type", ...)
etc. to set named bind variables for this query.
PreparedStatement 预设参数超过7位就会报错。替换新的jdbc驱动包即可解决问题。
目前发现ojdbc6.jar有此问题。
可去oracle官网下载最新的oracle驱动包
http://www.oracle.com/technetwork/apps-tech/jdbc-10201-088211.html
首先可以完爆微信等其他网页缓存问题的就是Cache Buster技术了。
Cache Buster是什么？ 这是一个技术学名。翻译过来就是缓存的克星。
其实就是url带随机数。
首先要知道，网页是无法控制浏览器进行缓存的。
如果不想要缓存，唯一的办法就是在url后面添加参数，比如http://www.ghostsf.com/?t=20170119
参数可以用时间戳或者各种随机数。很好用，完爆微信等其他网页缓存问题。
另外：
如果是静态html文件遇到微信缓存而无法及时更新问题，请在html标签中增加不存在的manifest文件链接：
根据HTML5 W3C规范，解析器下载manifest header 404/410时，缓存即失效（见
http://www.w3.org/TR/html5/browsers.html#downloading-or-updating-an-application-cache “5.7.4 Downloading or updating an application cache > 5.If fetching the manifest fails due to a 404 or 410”）
该方法对其它有自己缓存机制和缓存规则的应用也有奇效。
“你好，我是小程序”，小程序强势来袭。你的朋友圈被小程序霸占了吗？
但是ghostsf这里需要给大家说明的是，小程序背后的各种调整和限制：
小程序服务范围大调整：
社交与直播都能做了
首当其冲的是 2016 年的两大热词 —— 直播和共享都出现在了新的服务类目中。
「直播」出现在新分类「社交」中，与其并行的还有陌生人交友、熟人交友、社区/论坛、直播、婚恋、问答，而这些在之前都被认为是微信不希望小程序涉足的领域。
共享
「共享」则出现在了「出行与交通」中的「城市共享交通」。
2016 年共享单车大热，摩拜单车、ofo 等创业公司都是当红炸子鸡。
这类共享单车服务都很符合「小程序」的基本理念「用完即走」，开放了扫码接口，随后服务类目就出现了「共享交通」，不免让人遐想。
商家自营与政务民生
「商家自营」和「政务民生」都是变化较大的大类
其中「政务民生」下的小分类，更是从原先的 8 个暴涨到 61 个。
对普通用户来说，激增的分类、更多的场景也意味着 ——小程序将触手可及，且无处不在，你的生活将会再一次被改变。
根据微信的最新调整，整理出最新的服务范围表：
小程序的限制（克制）：
这里还是克制一词比较准确吧，哈哈（张小龙自己也说了，虽然他极力辩解）。
小程序没有入口，需要自己去发现（怎么去发现，ghostsf已经在上一篇说明了 微信小程序如期而至，你在发现里看到小程序了吗？）
以上，就是ghostsf整理的，小程序的相关调整和各种限制。
最近在做一个项目, 架构上使用了 Nginx +tomcat 集群, 且nginx下配置了SSL,tomcat no SSL,项目使用https协议
但是,明明是https url请求,发现 log里面,
0428 15:55:55 INFO (PaymentInterceptor.java:44) preHandle() - requestStringForLog: {
"request.getRequestURL():": "http://trade.feilong.com/payment/paymentChannel?id=212&s=a84485e0985afe97fffd7fd7741c93851d83a4f6",
"request.getMethod:": "GET",
"_parameterMap": {
"id": ["212"],
"s": ["a84485e0985afe97fffd7fd7741c93851d83a4f6"]
}
}
request.getRequestURL() 输出出来的 一直是
http://trade.feilong.com/payment/paymentChannel?id=212&s=a84485e0985afe97fffd7fd7741c93851d83a4f6
但是浏览器中的URL却是
https://trade.feilong.com/payment/paymentChannel?id=212&s=a84485e0985afe97fffd7fd7741c93851d83a4f6
瞬间要颠覆我的Java观尴尬,API上写得很清楚:
getRequestURL():
Reconstructs the URL the client used to make the request.
The returned URL contains a protocol, server name, port number, and server path,
but it does not include query string parameters.
也就是说, getRequestURL() 输出的是不带query string的路经(含协议,端口,server path等信息).
并且,还发现
request.getScheme() //总是 http，而不是实际的http或https
request.isSecure() //总是false（因为总是http）
request.getRemoteAddr() //总是 nginx 请求的 IP，而不是用户的IP
request.getRequestURL() //总是 nginx 请求的URL 而不是用户实际请求的 URL
response.sendRedirect( 相对url ) //总是重定向到 http 上 （因为认为当前是 http 请求）
查阅了一些资料,找到了解决方案:
解决方法很简单，只需要分别配置一下 Nginx 和 Tomcat 就好了，而不用改程序。
配置 Nginx 的转发选项：
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Proto $scheme;
配置Tomcat server.xml 的 Engine 模块下配置一个 Valve：
<Valve className="org.apache.catalina.valves.RemoteIpValve"
remoteIpHeader="X-Forwarded-For"
protocolHeader="X-Forwarded-Proto"
protocolHeaderHttpsValue="https"/>
配置双方的 X-Forwarded-Proto 就是为了正确地识别实际用户发出的协议是 http 还是 https。
这样以上5项测试就都变为正确的结果了，就像用户在直接访问 Tomcat 一样。
关于 RemoteIpValve,有兴趣的可以阅读下 doc：
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html
Tomcat port of mod_remoteip, this valve replaces the apparent client remote IP address and hostname for the request with the IP address list presented by a proxy or a load balancer via a request headers (e.g. "X-Forwarded-For").
Another feature of this valve is to replace the apparent scheme (http/https) and server port with the scheme presented by a proxy or a load balancer via a request header (e.g. "X-Forwarded-Proto").
看了下他们的源码,比较简单,在各种框架,各种算法面前,这个类对性能影响很小
其他设置为 http
if (protocolHeader != null) {
String protocolHeaderValue = request.getHeader(protocolHeader);
if (protocolHeaderValue == null) {
// don't modify the secure,scheme and serverPort attributes
// of the request
} else if (protocolHeaderHttpsValue.equalsIgnoreCase(protocolHeaderValue)) {
request.setSecure(true);
// use request.coyoteRequest.scheme instead of request.setScheme() because request.setScheme() is no-op in Tomcat 6.0
request.getCoyoteRequest().scheme().setString("https");
request.setServerPort(httpsServerPort);
} else {
request.setSecure(false);
// use request.coyoteRequest.scheme instead of request.setScheme() because request.setScheme() is no-op in Tomcat 6.0
request.getCoyoteRequest().scheme().setString("http");
request.setServerPort(httpServerPort);
}
}
转载自 飞天奔月的java博客
刚好ghostsf，也遇到一样的情况，刚好看到这位写的博文，遂转载之。
微信小程序如期而至，一月九日，一年之约
可是你们会发现即使已经将微信更新到最新版本，在发现里面也还是没有看到小程序。那么小程序的入口到底在哪里呢？ghostsf来教大家。
注，该方法适合微信最新版本！
方法一：扫二维码进入小程序（最简单的方法）
小程序已经在微信公众平台上线公布，可以在微信公众平台的公告里看到：
https://mp.weixin.qq.com/cgi-bin/announce?action=getannouncement&key=1483021481&version=9&lang=zh_CN
扫一扫微信小程序示例二维码，即可进入小程序。只要你进入了一次小程序，那么你的小程序就开通了，也就是说你可以在发现里面看到小程序那个菜单栏了，在这个小程序菜单里，你可以看到所有你已经用过的小程序了。
这里直接贴出微信小程序示例二维码，大家打开微信扫一扫，即可开启小程序了：
方法二：任意进入一个朋友分享的或者群里分享的小程序，那么即可打开小程序的入口了
需要注意的是，小程序是不能够在朋友圈分享的。小程序的搜索也只有在有了小程序的入口后，才可以进去搜索（而且搜索是很有限的）。
打开小程序入口后，你就可以看到小程序出现在发现里咯：
OK，那么，微信小程序的入口，和一些小程序长什么样子呢？
ghostsf给大家晒下，今天收集到的小程序：
哈哈，你们搜集到多少小程序了？2017.1.9，今天是个晒小程序列表的日子哦~
把你的小程序给大家分享分享啦~
上文ghostsf已给大家介绍了支付宝个人收款的申请开通方案：支付宝个人收款申请开通的方案
那么开通了支付宝个人收款，如何接入到自己的网站或者app应用里呢？
这边ghostsf给大家介绍下：
首先要进到蚂蚁金服开发平台openhome.alipay.com（当然关于支付宝和蚂蚁金服，还有支付宝开放平台以及蚂蚁金服开发平台等的区别和关系，这里就不赘述了）。如果之前已经申请到了个人收款。那么你就可以到这里来创建应用了。
创建应用之前，你需要先拿到Appid和RSA公钥，那么去哪里拿呢？要去蚂蚁金服商户平台去拿，商户平台的域名是b.alipay.com。
这里可以直接拿到。而且这边也提供了一个给你创建应用和编辑应用的入口。就是旁边的“编辑回调地址和LOGO”。点进去就会跳转到openhome.alipay.com的创建应用页面了。
这里将接口加签方式里面的方式设置一下即可，如果需要支付回调的话可以设置一下应用网关，回调信息会返回到应用网关里。这里需要说明的是，蚂蚁金服开放平台已于2016/12/30发布公告说明新增了RSA2签名方式，而且推荐使用之。所以这里ghostsf也是推荐使用RSA2签名方式。
另外，相关公钥的生成可以只用支付宝提供的RSA密钥工具，可以很方便地帮你获得应用公钥进而也可以获得支付宝公钥。
OK，到这里应用的相关设置已经完成了。
接下来就是程序的接入了。个人收款用到的是当面付的相关接口，所以我们可以使用支付宝的当面付SDK。
这里以php的当面付SDK为例：
在当面付的SDK里面已经集成了支付宝的支付相关的接口代码都在aop目录里。然后当面付相关参数所需，都在./config/config.php的配置文件里面，需要设置的主要是支付宝公钥（之前设置应用时已经设置了），商户私钥（这个在秘钥生成工具里已经给出了），以及应用的appid，异步通知的接口也即应用设置里的应用网关，用来接收异步通知（比如用户付款成功了的通知）。
这里有几个坑需要注意下。主要是异步通知验签的处理，多半也是因为新推出的RSA2的问题，SDK相关的代码也没有及时更新（ghostsf已提交了两个相关bug了）。
这里的rsaCheckV2的方法就是用来做RSA2方式的验证的。但是该方法默认传的是RSA的signType，这是个小问题，再一个是方法里面只去除了params的sign参数并没有排除掉sign_type参数（事实证明RSA2方式也是需要排除掉sign_type参数的）。
这里也给大家明确一下验签的正确过程（这在支付宝的开发文档里也可以看到）：
第一步： 在通知返回参数列表中，除去sign、sign_type两个参数外，凡是通知返回回来的参数皆是待验签的参数。
第二步： 将剩下参数进行url_decode, 然后进行字典排序，组成字符串，得到待签名字符串。
第三步： 将签名参数（sign）使用base64解码为字节码串。
第四步： 使用RSA的验签方法，通过签名字符串、签名参数（经过base64解码）及支付宝公钥验证签名。
第五步：需要严格按照如下描述校验通知数据的正确性。
所以这里需要说明的是RSA和RSA2的验签方式所需的条件是一样的，只是最后的验签方法不一样。
支付宝个人收款开通了如何接入自己的网站应用呢？
如以上代码所示。
OK，综上，在借用相关SDK可以帮助你很方便地对接网站，实现支付宝的个人收款。
支付宝的蚂蚁金服开发平台目前发布了当面付的 SDK，有几个好处，可以回调了！代表个人收款的时代来了！So！怎么申请开通呢？
ghostsf相信很多人是找不到入口的，更找不到申请开通的入口了。（至于为什么，你猜？）
首先这里，一张图来说明下个人开通支付宝商家收款码的特点以及申请开通的二维码（支付宝打开扫码后即可进入开通页面了）：
扫了申请开通的二维码后，就可以直接申请开通了。
点击立即开通，然后填写一些基本信息，就可以秒审核通过了。
审核通过基本就开通成功了。
所以这时候就是已经开通收款了。这里的扫码激活，其实就不用扫码激活了，已经开通成功了。
那么你的个人收款码在哪儿呢？
就在蚂蚁金服商家平台号的我的收款码里，打开后就可以看到你的个人收款码啦。
可以保存下来备用。
这样你的支付宝个人收款就开通实现了。
前言：之前ghostsf随意装了一个docker，docker的存储驱动为Devicemapper。这次索性也就将底层的docker版本也升级到新版，并更改Devicemapper为overlayfs。
由于操作系统是CentOS Linux release 7.1.1503 (Core)，内核版本3.10.0-229.el7.x86_64，该内核版本已经支持overlayfs。但是由于新的内核4.9已经发布，在4.9的内核版本中，对硬件和文件系统方面的改进也很多，涉及到 Btrfs、XFS、F2FS、OverlayFS 的 UBIFS 支持、FUSE 支持 POSIX ACL、OverlayFS SELinux 等方面。所以本次也将内核版本升级到4.9。
1，系统环境
Centos 7
Kernel Version: 3.10.0-->4.9.0
Storage Driver: DeviceMapper-->Overlayfs
一：升级Kernel版本
(1)安装yum源
$ rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
Retrieving http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
warning: /var/tmp/rpm-tmp.X3PpyZ: Header V4 DSA/SHA1 Signature, key ID baadae52: NOKEY
Preparing... ################################# [100%]
Updating / installing...
1:elrepo-release-7.0-2.el7.elrepo ################################# [100%]
(2)安装Kernel
$ yum -y --enablerepo=elrepo-kernel install kernel-ml-devel-4.9.0 kernel-ml-4.9.0
=======================================================================
Package Arch Version Repository Size
=======================================================================
Installing:
kernel-ml x86_64 4.9.0-1.el7.elrepo elrepo-kernel 39 M
kernel-ml-devel x86_64 4.9.0-1.el7.elrepo elrepo-kernel 11 M
Transaction Summary
========================================================================
Install 2 Packages
Installed:
kernel-ml.x86_64 0:4.9.0-1.el7.elrepo
kernel-ml-devel.x86_64 0:4.9.0-1.el7.elrepo
(3)检查当前版本
$ uname -r
(4)检查kernel启动顺序
$ awk -F\' '$1=="menuentry " {print $2}' /etc/grub2.cfg
CentOS Linux (4.9.0-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (4.9.0-1.el7.elrepo.x86_64) 7 (Core) with debugging
CentOS Linux 7 (Core), with Linux 3.10.0-229.el7.x86_64
CentOS Linux 7 (Core), with Linux 0-rescue-f7e36a944a3d4035a61da37d8d4e2313
(5)设置启动kernel
根据上面检查kernel启动顺序自上而下，从0开始的顺序。如果设置4.9启动那么如下命令
$ grub2-set-default 0
重启
$ reboot
(6)检查kernel版本
$ uname -r
Kernel 升级完毕！！！！
二：Docker的升级、卸载、安装
(1)关闭docker进程,卸载老版本
$ systemctl stop docker
$ rpm -qa|grep docker
docker-engine-1.9.1-1.el7.centos.x86_64
docker-storage-setup-0.5-3.el7.centos.noarch
docker-engine-selinux-1.9.1-1.el7.centos.noarch
$ rpm -e docker-engine-1.9.1-1.el7.centos.x86_64
$ rpm -e docker-engine-selinux-1.9.1-1.el7.centos.noarch
(2)安装新版本
$ wget https://yum.dockerproject.org/repo/main/centos/7/Packages/docker-engine-selinux-1.12.2-1.el7.centos.noarch.rpm
$ wget https://yum.dockerproject.org/repo/main/centos/7/Packages/docker-engine-1.12.2-1.el7.centos.x86_64.rpm
使用yum命令可以解决依赖问题，如果直接rpm命令安装可能会报错。
$ yum install -y docker-engine-selinux-1.12.2-1.el7.centos.noarch.rpm
$ yum install -y docker-engine-1.12.2-1.el7.centos.x86_64.rpm
安装最新版本的docker也可以采用下面这种方案：
官方支持 devicemapper，但是这东西一直出问题，应该说 Docker 跑在 devicemapper 上都不稳定。所以你要找办法装 aufs。你要装一个支持 AUFS 的内核，然后 Docker 应该就不会退而求其次地用 devicemapper 了
1. 将OverlayFS加到module目录下
$ echo "overlay" > /etc/modules-load.d/overlay.conf
2. reboot 系统，执行lsmod看时候看到overlay
$ lsmod | grep over
overlay 42451 0
3. 将Docker源添加到系统里
$ cat >/etc/yum.repos.d/docker.repo<<E
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
E
到/etc/yum.repos.d/docker.repo查看baseurl的路径
https://yum.dockerproject.org/repo/main/centos/7/---centos7
https://yum.dockerproject.org/repo/main/centos/6/----centos6
配置Docker Daemon用OverlayFS启动
$ sudo mkdir -p /etc/systemd/system/docker.service.d
sudo cat >/etc/systemd/system/docker.service.d/override.conf <<E
[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon –storage-driver=overlay -H fd://
E
–说明
在修改docker启动配置时docker.service原来的默认配置中是这样的
ExecStart=/usr/bin/dockerd -H fd://
当我改成
ExecStart=/usr/bin/docker daemon –storage-driver=overlay -H fd://
启动的时候，docker报错了。
重点：在github查到了这个更新。1.12版本之后这个配置发生了改变。解决办法中将-H fd://从ExecStart指令中删除，改成如下方式解决。
ExecStart=/usr/bin/dockerd daemon –storage-driver=overlay
就成功了！
每次修改conf配置文件都得执行
# systemctl daemon-reload
5. 安装Docker，设置开机自启动
$ sudo yum -y install docker-engine
$ sudo sysctemctl start docker
$ sudo systemctl enable docker
Docker info 看一下，如果看到
Storage Driver: overlay
那就证明更改成功，已经从Devicemapper换到了ovelay了（这也是个比较蛋疼的点，ghostsf曾用Devicemapper把CPU跑到了100%，= =）。
（3）检查新的docker版本
$ docker -v
Docker version 1.12.2, build bb80604
Docker升级完毕！！！
三：安装discourse
(1)安装 discourse
$ sudo -s
$ mkdir /var/discourse
$ git clone https://github.com/discourse/discourse_docker.git /var/discourse
$ cd /var/discourse
(2)配置 app.xml
app 的名称自取，此处直接命名为 app。
拷贝默认配置文件
$ cp samples/standalone.yml containers/app.yml
配置 ruby 国内源
在 app.yml 添加一行 templates/web.china.template.yml。
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
- "templates/web.china.template.yml"
配置默认端口
这里改默认端口为 10080。
expose:
“10443:443” # https
配置邮箱
用于 administrator 的激活邮件。至关重要！
此处用的 163 邮箱。
env:
LANG: en_US.UTF-8
#UNICORN_WORKERS: 3
DISCOURSE_HOSTNAME: ‘172.18.xxx.xxx’
#DOCKER_USE_HOSTNAME: true
DISCOURSE_DEVELOPER_EMAILS: 'your@163.com‘
DISCOURSE_SMTP_ADDRESS: ‘smtp.163.com’ # required
DISCOURSE_SMTP_PORT: 25 # (optional, default 587)
DISCOURSE_SMTP_USER_NAME: 'your@163.com‘ # required
DISCOURSE_SMTP_PASSWORD: ‘password’ # required, WARNING the char ‘#’ in pw can cause problems!
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default true)
DISCOURSE_SMTP_AUTHENTICATION: login
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
强调：
如果服务器是阿里的则要添加上：
DISCOURSE_SMTP_AUTHENTICATION: login
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
如果服务器是国外的则不需要添加：
配置邮件的默认发送者：
将 ##- exec: rails r “SiteSetting.notification_email… 的 # 号去掉，并把邮箱设置为你自己的邮箱。
## Any custom commands to run after building
run:
- exec: echo "Beginning of custom commands"
## If you want to set the 'From' email address for your first registration, uncomment and change:
## After getting the first signup email, re-comment the line. It only needs to run once.
- exec: rails r "SiteSetting.notification_email='your@163.com'"
- exec: echo "End of custom commands"
调试邮件发送情况，查看 Log 文件 shared/standalone/log/rails/production.log。一个样例：
Sent mail to sunnogo@163.com (20111.6ms)
Job exception: end of file reached
Sent mail to sunnogo@163.com (20241.3ms)
Job exception: end of file reached
编译、启动 app
bootstrap 或 rebuild 的时间很长，特别是第一次运行时，要下载多个组件。
sudo ./launcher bootstrap app
sudo ./launcher start app
即可登陆你的 discourse 论坛开始配置了。
关于微信的订阅号，服务号还有企业号的区别，我就不多阐述了，微信相关文档上也有了详细的说明。
但是呢，还是有很多人，包括很多开发者，也很难讲清楚，订阅号和服务号的区别，这里就不谈企业号了（这是另一回事了）。
那么订阅号和服务号本身的区别有哪些呢？ 本来想放一个图好好说嘛下的，现在想想还是算了。指不定等你看到这篇文章的时候，微信已经修改了相关设定。目前具体的，可以参考微信的官方文档了。
但是这里需要说的一个痛点是微信订阅号不能实现网页授权获取用户基本信息，即使微信认证了也不可以的。只有认证了的服务号才可以用网页授权，但是服务号有个痛点，也是很多人比较尴尬的，就是每个月只能群发图文4次（以前每个月只能1次）。当然并不是吐槽这个设定有多不好，只是确实有这样的需求，就是既要每个月每天都可以群发图文，也要可以实现网页授权进行一些高级的功能定制。
好了，以上把这一问题抛露出来，下面ghostsf给大家介绍两个实现方案：
方案一：
主要是利用UnionID机制。这里可以把UnionID机制再阐述一下：
UnionID机制说明： 开发者可通过OpenID来获取用户基本信息。特别需要注意的是，如果开发者拥有多个移动应用、网站应用和公众帐号，可通过获取用户基本信息中的unionid来区分用户的唯一性，因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号，用户的unionid是唯一的。换句话说，同一用户，对同一个微信开放平台下的不同应用，unionid是相同的。
以上这段说明来自微信官方文档。由此可知，基于微信开放平台可以统一多个移动应用、网站应用和公众帐号（当然这里主要讲公众号）。在不同的公众号下，用户的unionid是唯一的。可以利用此机制借用认证过的服务号间接地实现订阅号的网页授权。
具体实现方案的思路就是：
注册一个微信开放平台，在开放平台上绑定上认证过的服务号以及订阅号。当然这里的认证过的服务号你可以去找别人的服务号借用一下（也有一些第三方的服务平台，可以借用，这里就不多阐述了）。这个时候，在订阅号上，借用服务号的网页授权接口，auth授权后会返回openid（当然这个是服务号的用户openid），同时也会返回该用户的unionid，这个unionid是唯一的。绑定了开放平台的订阅号也能获取到该用户的unionid，获取的方案可以是从消息回调里获得unionid（当然可以在关注的时候直接获取并存储到数据库里）。这样通过unionid关联即可间接地获得订阅号的openid，此后就可以用订阅号的用户openid来区分用户进行相关业务逻辑处理了（当然也可以直接根据unionid来处理），从而实现了订阅号的auth网页授权。
方案二：
这个方案是利用了开放平台网站应用网页授权接口本身的一个缺陷（或者说漏洞吧）。
首先可以先看下相关文档：https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1419316505&token=&lang=zh_CN
同样需要用到网站应用，那么需要在开放平台上创建一个网站应用（如果你已经创建过了，那可以忽略）。
如果直接使用开放平台的网站应用的微信登录功能，只能出现基于二维码的扫一扫页面，并且只适用于pc端的微信登录。
那么如何给订阅号来用呢？下面注意看了：
开放平台官方提供的认证地址是：https://open.weixin.qq.com/connect/qrconnect?xxxxxx
它会生成一个二维码需要微信扫描登陆后获取信息，这和微信公众号网页授权自登录相差太远了。
这里披露一个缺陷（或者说漏洞），即更换上面的认证地址为：https://open.weixin.qq.com/connect/oauth2/authorize?xxxxx
目前这个接口地址，微信是没写入开放平台的官方文档的，但是却可以实现订阅号的微信网页授权，不过和服务号的OAuth不同的是，这种方式是登陆操作（scope必须只能设置成snsapi_login），不是snsapi_base或者snsapi_userinfo。
当然这里的appid填写的是网站应用的appid而不是订阅号的appid，这里的redirect_uri是在订阅号上需要授权后跳转的地址。
在授权跳转的地址里，即可获取到access_token以及openid。
至此即可借用此接口实现订阅号的网页授权的相关开发了。
By ghostsf 原创声明:本文为作者原创，未经允许不得转载，经授权转载需注明作者和出处