这个图很好地概况了功能对比：

使用letsencrypt免费SSL证书的问题
证书到期了，要续期了，自动续期出错了。

Invalid response for ACME challenge 

大概提示如下：

IMPORTANT NOTES:
   - The following errors were reported by the server:

   Domain: bbs.6doors.org
   Type:   unauthorized
   Detail: Invalid response from
   http://bbs.6doors.org/.well-known/acme-challenge/ZLsZwCsBU5LQn6mnzDBaD6MHHlhV3FP7ozenxaw4fow:
404

主要问题是服务器配置问题：
如 nginx 里应如此配置一下：

location ~ /.well-known/acme-challenge/ {
    allow all;
}

然后重启nginx，重新生成证书，然后就OK了。

相信很多人是喜欢用印象笔记的，比如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已经在上一篇说明了 微信小程序如期而至，你在发现里看到小程序了吗？）

• 朋友圈不能分享小程序
• 小程序的体积只能在1M之内
• 小程序限制搜索，搜索功能是很有限的
• 小程序尚不能做游戏
• 小程序二维码只能通过微信扫一扫进入，不能通过识别二维码进入
• 小程序的设计有一列的规范要求
• 小程序强势来袭，可是你看到小程序背后的调整和限制了吗？
• 小程序的运营有一系列规范要求
• 小程序强势来袭，可是你看到小程序背后的调整和限制了吗？
• 没有中心化应用市场，也没有小程序应用排名
• 小程序不能主动推送消息
• 小程序不应有分析，只有访问量（当然你如果做了用户系统也不是不可以）

以上，就是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").   

看了下他们的源码,比较简单,在各种框架,各种算法面前,这个类对性能影响很小

• 如果没有配置protocolHeader 属性, 什么都不做.
• 如果配置了protocolHeader,但是request.getHeader(protocolHeader)取出来的值是null,什么都不做
• 如果配置了protocolHeader,但是request.getHeader(protocolHeader)取出来的值(忽略大小写)是配置的protocolHeaderHttpsValue(默认https),scheme设置为https,端口设置为 httpsServerPort

• 其他设置为 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相信很多人是找不到入口的，更找不到申请开通的入口了。（至于为什么，你猜？）

首先这里，一张图来说明下个人开通支付宝商家收款码的特点以及申请开通的二维码（支付宝打开扫码后即可进入开通页面了）：

扫了申请开通的二维码后，就可以直接申请开通了。

点击立即开通，然后填写一些基本信息，就可以秒审核通过了。

审核通过基本就开通成功了。

所以这时候就是已经开通收款了。这里的扫码激活，其实就不用扫码激活了，已经开通成功了。

那么你的个人收款码在哪儿呢？

就在蚂蚁金服商家平台号的我的收款码里，打开后就可以看到你的个人收款码啦。

可以保存下来备用。

这样你的支付宝个人收款就开通实现了。