Epic Store 购买攻略

垃圾 Epic Store!

垃圾 Epic Store!

垃圾 Epic Store!

好了,说正事。

由于某些众所周知的原因,我们只能想办法在 Epic Store 上购买一些想玩的大作。但是作为一个新兴的平台,付款之路坑实在太多,在这记录一下。

TL;DR

对没有国外信用卡的人来说,中国发行的 Visa/MasterCard/AE 等信用卡,配上账号所在区域的 PP 账号,就可以支付成功。

下面来详细说明:

  1. 先进 Account 看你的账户所在区域
  2. IP 跟账户的区域无关,只要 IP 不是大陆的,账户区域不是中国就可以
  3. 在购买成功之前,账号区域可以修改。如果已经不可修改,找客服吧
  4. 中国大陆发行的信用卡直接被拒绝
  5. 账户所在区域的 PP 关联大陆卡之后,可以成功

新版 Mac U 盘重装系统的注意事项

由于苹果在新版的 Mac 中内置了 T2 安全芯片,因此当我们在下面这些版本的 Mac 上尝试使用 U 盘重装系统的时候,需要额外注意。

本文章适用的 Mac 型号包括:

主要注意的核心点是:

  1. 不要先格式化硬盘
  2. 不要先删除原系统中的管理员用户
  3. 切记先进 Recovery 模式修改安全芯片选项,再开始重装
  4. 最好先升级到最新的系统再重装

说说原因:

  1. 如果先格式化硬盘,Recovery 模式无法找到有效的管理员账号,不允许修改 T2 芯片的选项
  2. 同 1,删除所有管理员账户会导致无法修改选项
  3. 将安全芯片选项修改为 No Security + Allow booting from external media 之后,再进行重装,防止重装操作被安全芯片拦截。
  4. 遇到很多诡异的问题就算将安全芯片选项修改了也不生效。但是有时候又是生效的。所以最好升级到最新的啦

https://support.apple.com/en-us/HT208330

华为 EMUI 8.0 免登录账号开启 ADB 方法

这两天拿到一台新的华为 Mate 10,准备自己折腾一下。但是在打开开发者选项,准备开 ADB 的时候,却发现必须要我登录华为账号才能开启。这就很烦人了,我并不想登录。于是搜了一下解决方案,发现网上说到这个事情的不多,而且步骤不太正确。这里记录一下正确的方法。

首先贴官方回复:

打开USB调试开关需要先登录华为账号问题现象:
在没有登录华为账号的情况下,打开开发者选项中的USB调试开关时,会提示请先登录华为账号。
在已登录华为账号的情况下,可以正常打开开发者选项中的USB调试开关。

问题原因:
华为公司收到了部分用户反馈第三方应用使用过程中遇到稳定性、推送广告、后台耗电等问题,经过调查发现,造成这些问题的原因是部分三方应用被通过USB调试端口自动安装到手机。为了使您能够更流畅、更放心的使用手机,保护您的隐私以及合法权益,避免以上问题出现,华为公司添加了对USB调试开关的身份确认,打开USB调试开关时需要登录华为账号,感谢您的理解与支持!

非华为手机出厂预装的第三方应用会有以下危害:
1.使用非华为手机出厂预装的第三方应用容易引起软件卡顿、手机发热、耗电快等问题,影响您对于手机的体验感知度;
2.使用非华为手机出厂预装的第三方应用,可能会在未经您允许情况下,向您推送一些广告。

解决方案(仅适用于网点维修):
维修工具使用注意事项
ComPartner工具的使用,注意以下事项:

建议方案:使用HDB连接(HDB不受USB调试管控影响,无需输入华为帐号):
在“设置”->“安全和隐私”->“更多安全设置”界面,确认已打开“允许HiSuite通过HDB连接设备”开关按钮;

连接USB数据线,选择“传输文件”选项。

备用方案:EMUI8.1、EMUI8.2版本也可以使用ADB连接
在拨号界面输入*#*#2846579#*#*进入工程模式;
选择“1.后台设置”->“2.USB端口设置”->“生产模式”,系统自动打开USB端口。

备注:
高维和生产环境已做了针对性适配,可以直接打开USB调试;
华为手机助手(HiSuite)使用不受影响;
Root过的手机可以直接打开USB调试;
ComPartner工具版本号为5.1.21.02,通过以上方式打开,已验证没有问题。

注意最下面的备用方案,虽然说是 EMUI8.1 8.2 使用,但是我实测 8.0 也可以用。

不过这里在操作的时候有顺序要求,经过测试,应该这样:

  1. 先打开开发者选项备用,先开启仅充电模式下调试
  2. 拔掉 USB 连接线,注意必须先拔线,操作前不要联电脑
  3. *#*#2846579#*#*进入工程模式
  4. 选择“1.后台设置”->“2.USB端口设置”->“生产模式”
  5. 进入之前已经开启过的开发者选项界面备用
  6. 插上 USB 线,选仅充电,打开 adb
  7. 在弹出窗口中进行授权。注意这个弹窗很坑,如果你当前不是停留在开发者选项的页面,那么不会弹窗

如果这样操作还是打不开的话,拔掉线重来一次。千万注意操作顺序!

Kapacitor 使用 Proxy 连接小电报 API

由于众所周知的原因,小电报的 Bot API 在某些地方是完全无法访问的。

那么,这导致我们最好用,最快捷的告警方式被掐死了。

于是研究了一下,发现官方有一个回复:

https://community.influxdata.com/t/how-to-set-proxy-for-telegram-and-smtp/3250

The Kapacitor 你懂的 agent uses the golang HTTP client, so you can set that with the environment variables $http_proxy (or $https_proxy). As for SMTP, we don’t currently have logic in place for that, but that sounds like a great feature request.

于是加入环境变量,结果发现一个新问题。由于 Kapacitor 与 InfluxDB 之间的连接也是 HTTP 的,导致 InfluxDB 也走了代理,反而导致不通了。于是再次尝试,发现可以使用 NO_PROXY 变量,最终结果如下:

HTTP_PROXY=http://x.x.x.x:xxxx
HTTPS_PROXY=http://x.x.x.x:xxxx
NO_PROXY=influxdb.xxx.xxx

 

下载中文商业版的 WinRAR(非加料版)

众所周知,因为某些蛋疼的原因,现在市面上比较容易下载到的 WinRAR 的中文版都变成了非商用个人版。就算是从 rarlab 或者 其他外国官网通过科学方式,下载到的也是加料版。

具体表现为,安装的时候,许可协议有这么一行字:

安装之后的表现为,每次打开都有广告弹窗,怎么都关不掉。

于是思考了一下,这玩意虽然说个人只给非商业个人版,但是总有人购买的。不可能把这个加料版发给购买用户的。那么就一定有一个地方可以下载未加料的安装包,也就是商业版的安装包。

经过一番查找,果然让我找到了!下载之后安装界面是这样的:

成功!终于不用改 DLL 来解决这个烦人的广告啦~

忘了之前是怎么抓到的这个地址。印象中是在下载别的版本的试用版的时候这个地址被漏出来了,然后通过穷举可以拿到最新的地址。

也有可能是搜索到了相关的下载链接。具体的没印象了。可以看到网上相关链接还是挺多的。

下载地址:

6.21 https://www.win-rar.com/fileadmin/winrar-versions/sc/sc20230223/wrr/winrar-x32-621sc.exe

6.02 https://www.win-rar.com/fileadmin/winrar-versions/sc/sc20210616/wrr/winrar-x64-602sc.exe

6.00 https://www.win-rar.com/fileadmin/winrar-versions/sc/sc20201210/wrr/winrar-x64-600sc.exe

5.91 https://www.win-rar.com/fileadmin/winrar-versions/sc/sc20200708/wrr/winrar-x64-591sc.exe

5.80 https://www.win-rar.com/fileadmin/winrar-versions/sc/sc20191217/wrr/winrar-x64-580sc.exe

5.71 https://www.win-rar.com/fileadmin/winrar-versions/sc20190509/wrr/winrar-x64-571sc.exe

5.70 https://www.win-rar.com/fileadmin/winrar-versions/sc20190304/wrr/winrar-x64-570sc.exe

减少 Mac – Office365 网络请求和流量

在功能和使计算机保持最新状态这两个方面,Office 2016 for Mac 的默认配置提供了最佳用户体验。

在某些情况下,可能希望阻止应用程序联系网络终结点。

若要防止应用程序发送“使用情况”遥测可从终端手动设置:

defaults write com.microsoft.WordSendAllTelemetryEnabled -bool FALSE
defaults write com.microsoft.WordSendAllTelemetryEnabled -bool FALSE
defaults write com.microsoft.ExcelSendAllTelemetryEnabled -bool FALSE
defaults write com.microsoft.PowerpointSendAllTelemetryEnabled -bool FALSE
defaults write com.microsoft.OutlookSendAllTelemetryEnabled -bool FALSE
defaults write com.microsoft.onenote.mac SendAllTelemetryEnabled -bool FALSE
defaults write com.microsoft.autoupdate2 SendAllTelemetryEnabled -bool FALSE
defaults write com.microsoft.Office365ServiceV2 SendAllTelemetryEnabled -bool FALSE
defaults write com.microsoft.WordSendASmileEnabled -bool FALSE
defaults write com.microsoft.ExcelSendASmileEnabled -bool FALSE
defaults write com.microsoft.PowerpointSendASmileEnabled -bool FALSE
defaults write com.microsoft.OutlookSendASmileEnabled -bool FALSE
defaults write com.microsoft.onenote.mac SendASmileEnabled -bool FALSE
defaults write com.microsoft.errorreportingIsAttachFilesEnabled -bool FALSE

(Copy以上命令行,打开 Mac – 终端,粘贴进去,回车就行了。已包含反馈调查和故障报告)

禁用说明:

遥测

Office 2016 for Mac 会定期将遥测信息发送回 Microsoft。

向“Nexus”终结点上传数据。

遥测数据可帮助工程团队评估每个 Office 应用的运行状况和任何意外行为。

遥测分为两类:

Ø 检测信号包含版本和许可证信息。应用启动时此数据会立即发送。

Ø 使用情况包含应用的使用情况和不严重的错误。此数据每 60 分钟发送一次。

注意:检测信号将始终发送遥测,无法禁用。

 

反馈和调查

使用 Office 2016 for Mac 有可能需要提供 Office 体验反馈。

微软根据反馈内容不断改进产品、了解新功能请求和评估客户对产品改动的满意度。

反馈分为两种类别:用户反馈和调查。

Ø 用户反馈由 Office 使用者发起。他们可以提交评论,或者可选择提供屏幕截图和电子邮件地址。

Ø 调查由 Office 发起,显示为可关闭的通知消息。可以提交评分,同时可选择提交评论。每 3 个月最多请求 1 次调查。

可以在 Office 中基于每个应用程序禁用反馈和调查。

 

故障报告

应用程序出现严重错误时,该应用程序将意外终止并将故障报告上传到“Watson”服务。

故障报告包括一个调用堆栈,它是应用程序所处理并导致故障的步骤列表。

这些步骤可帮助微软工程团队确定失败的确切函数以及原因。

在某些情况下,文档的内容将导致应用程序出现故障。

如果应用将文档标识为原因,它会询问用户是否可以将文档与调用堆栈一起发送。

用户可以在了解信息的情况下对此问题作出选择。

为防止发送文档并禁止向用户显示提示

IPv6 地址处理时的小 Bug

众所周知,IPv6 地址中可以用 ::  来省略一连串的 0,于是,在某些情况下,如果 0 被过度合并了,就会导致地址解析的问题。

最近在 AWS 上启用 IPv6 的时候就遇到了这个情况,AWS 分配给我的地址段是:

2406:da14:5c9::/56

可以看出,AWS 实际给我分配的地址是:

2406:da14:5c9:0000::/56

但是由于连续 0 的省略策略,导致 5c9 之后的真正可以被划分的部分被省略了。于是在 AWS 的系统中,子网划分页面就显示成了这样:

2406:da14:5__::/64

按照正常逻辑应该是这样:

2406:da14:5c9:00__:/56

结果当然就悲剧了。这里我除了填 c9 之外,任何的值都会导致划分出的子网不在上面的地址段内,导致划分失败。

所幸的是 AWS 的系统可以随意的解绑地址段,然后重新分配。于是重新分配之后就好了。

不过这里也是对我们的一个提醒:由于 IPv6 地址书写的特殊性,连续 0 会被缩写,那么在进行地址读取和判断的时候,就一定要先做 ::  的展开,再去做判断哦。

 

MyBatis 获取自增 ID 的小坑

在 MyBatis 中,获取自增 ID 主要有两个方法:

  1. 在 SQL 中增加两个属性,useGeneratedKeys  和 keyProperty
  2. 增加 selectKey  语句块,执行自定义 SQL 获取自增 ID

针对这几种方法,有几个小问题需要注意:

  1. useGeneratedKeys  是基于 JDBC 的 Prepared Statement  实现的,具体做法是调用 JDBC 的 getGeneratedKeys  方法,在 Prepared Statement  对象中取相应的值。当 DB 为 MySQL 的时候,会在响应时返回相应的自增字段值。但是,在某些实现 DB 分库分表的 Proxy 中,由于涉及 SQL 转换、重写的问题,可能对 Prepared Statement  的支持并不完整,导致 useGeneratedKeys  选项无法正常返回对应的自增 ID
  2. selectKey  方式是 MyBatis 自动的在执行完 Insert 语句之前/后自动执行对应的语句块,去生成/获取对于的 ID,并填充进相关的字段。在这里要注意,在某些 Prepared Statement  支持不完整的 Proxy 中,需要增加 statementType=”STATEMENT”  来强制指定不使用 Prepared Statement  来获取 ID
  3. keyProperty 这个参数也有一点需要注意。如果在 Mapper.java 中使用了 @Param  来对传入的参数进行了命名的话,这里接收自增值的属性需要用 paramName.fieldName  这种方式来写。如果只写 fieldName 则无法成功回传。最好的方式是不要用 @Param  来传参,而是全部封装成 bean 来进行传递

Nginx 诡异 SSL_PROTOCOL_ERROR 问题排查

这两天在检查一台 Nginx 配置的时候,遇到了一个极端诡异的问题。一段很通用的配置,配在这个服务器上,就会 100% 导致 Chrome 报 ERR_SSL_PROTOCOL_ERROR 。但是这段配置非常的通用,是用 Mozilla 提供的工具生成的。

而且在 iPhone 的 Safari 上访问又是完全正常的,服务器日志也看不到任何错误。看到的请求相应码也是完全正确的 200 。

先贴出配置:

# https://mozilla.github.io/server-side-tls/ssl-config-generator/
    listen 443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;


    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;

可以看到是在 Mozilla 网站上选择  和 Modern 生成出来的配置。

在测试过程中,排查了各种问题,包括但不限于 SSL 证书问题,HTTP Basic Auth 问题,http2 问题等等,然而都没有解决这个现象。

一次偶然的尝试,发现只要注释掉我给这个 server 特殊配置的这段逻辑,使用服务器通用的 ssl.ngx 文件中的 SSL 配置,就不会出现问题。于是开始先使用 ssl.ngx 文件中的配置,然后逐行替换,来查找具体出现问题的配置。

终于,当我将配置中的这行加上时,问题出现了:

ssl_session_tickets off;

于是以这个配置作为关键字搜索,找到了这么一篇文章:

https://community.letsencrypt.org/t/errors-from-browsers-with-ssl-session-tickets-off-nginx/18124/5

I’m posting this here both because this question was recently asked and because it took me many hours of troubleshooting to figure out the issue as while I found several references to the problem on Google, no one seemed to have a real solution. So here it is:

ssl_session_tokens off breaks if it’s not set the same for all ssl-enabled server{} blocks. So if you have 2 server configurations and and you have ssl_server_tokens set to on in one (which is the default so it counts even if you omit it) and set to off in another, it will break the one where it’s set to off in certain browsers. The easiest way to resolve this, unless you have multiple http{} blocks, is to just set it to off in the http{} block. I have not tested to see if you you can have different settings in different http{} blocks as I haven’t had need to set up more than one http{} block.

For others looking for this issue, I want to add that Chrome will respond with: ERR_SSL_PROTOCOL_ERROR while Firefox responds with: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET and curl responds with: gnutls_handshake() failed: An unexpected TLS packet was received. IE seemed to work, surprisingly.

简单翻译一下,这里是说,如果你的 nginx 开了多个 https 的 server,其中某些 server 没有配置 ssl_server_tokens off; ,而有些 server 配置了这个选项,那么就会导致没有手动 off 的 server 采用默认值 on,而手动 off 掉的 server 采用 off。这种情况会导致 nginx 和浏览器之间的握手出现问题,从而导致 Chrome 报出 ERR_SSL_PROTOCOL_ERROR ,FireFox 则会报出 SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET 。

那么解决方法也很简单,只要在所有的 server 块统一这个配置就好了。要么都设置为 on,要么都设置为 off,问题解决。目前没有尝试多个 http 块隔离两个 server,建议还是将这个配置统一一下。