使用app或者web端找到目标店铺，分享给微信好友或文件传输助手
使用PC登录微信，点击打开店铺链接
点击复制链接按钮，复制店铺链接到剪切板
粘贴店铺链接会得到
https://mobile.yangkeduo.com/mall_page.html?refer_share_id=kBwDgBBtmx6d6i1FOOipaJ7IRBTjTbDZ&refer_share_uid=3645162710&_wv=41729&refer_share_channel=message&share_uid=3645162710&mall_id=9870859&_wvx=10
找到其中的mall_id=9870859字段, 9870859 就是店铺ID了。
Visual Studio Code是现今最流行的编辑器，我也是从Sublime转过来的，一见面就爱不释手，尤其是它强大的生态系统，丰富的插件。
众所周知VS Code是基于Electron开发，打开VS Code的开发工具，你会发现它就是一个在Chrome上渲染的WEB应用，加上远程开发的需求所以VS Code Online的到来是迟早的事情，微软在5月份宣布了Web版的VS Code，但是迟迟不见上线，手痒的话可以先尝尝同人。
code-server是一个在服务器上搭建VS Code Online项目，基于官方的源码打了一些patch来完全剥离前后端。最新发布的是code-server v2预览版，很多功能已经比较稳定，支持了直接从官方源安装插件和语言包，但是最新的releases有较多Bug，我重新从源码编译了程序，并打包了中文语言，可以做到开箱即用。
默认简体中文，可以搭配利用Nginx快速搭建OAuth2.0 SSO单点登录系统，既可以作为远程开发的辅助，也可以当作WebShell管理服务器。
Google Cloud Shell是Google Cloud的一个Shell环境，默认集成了很多开发环境和Google Cloud SDK可以方便的管理云资源，它本身是一台 Docker 虚拟机，$HOME有5G永久磁盘，但是要求必须在120天内访问过，否则就会清空。其他目录的修改断开连接一小时后就会重置，空间不足的问题可以通过 gcsfuse my-bucket ~/my-bucket 映射Cloud Storage到本地。
支持网页预览，网页登录后访问 https://ssh.cloud.google.com/devshell/proxy?port=8080会指向Cloud Shell的8080端口，端口切换需要在网页端设置。
启用增强模式后在24小时内会提高主机性能，但每周有60小时使用时限，Cloud Shell的定位就是一台远程开发机，不能24小时运行，如果需要更强的性能可以尝试自定义环境。
说Cloud Shell是Google为开发人员发放的福利也不为过。
_,met$$$$$gg.
,g$$$$$$$$$$$$$$$P. OS: Debian 9.9 stretch
,g$$P"" """Y$$.". Kernel: x86_64 Linux 4.19.44+
,$$P' `$$$. Uptime: 8h 49m
',$$P ,ggs. `$$b: Packages: 590
`d$$' ,$P"' . $$$ Shell: bash 4.4.12
$$P d$' , $$P Disk: 31G / 45G (68%)
$$: $$. - ,d$$' CPU: Intel Xeon @ 2.2GHz
$$\; Y$b._ _,d$P' RAM: 856MiB / 3697MiB
Y$$. `.`"Y$$$$P"'
`$$b "-.__
`Y$$
`Y$$.
`$$b.
`Y$$b.
`"Y$b._
`""""
但是目前使用Cloud Shell只能在网页端，ALPHA SDK中提供的SSH访问方式，我本地测试没有成功唤起PuTTy，这样以来就感觉Cloud Shell离我们的距离有些远，要是能集成到Visual Studio Code那该多好，经过一番折腾后总算是能顺畅使用了，把结果分享在这里，也做个记录。
假设我们起了一个服务器在 1234 端口，但是我暴露在公网上，但是又需要被授权的人方便的使用，一般情况下我们会在程序里简单加一个密码验证，或者直接使用 Auth_Basic 设置一个用户名与密码。Nginx Auth_Basic 扫描是恶意爬虫最喜欢干的事，而限制 Auth_Basic 重试次数又需要配置 Fail2ban 之类的日志监控程序，很麻烦。
在应用层设置密码对大多数开发人员来说并没有什么难点，但是有时候我们搭建的系统并不是自己开发的，甚至是已经编译好的庞然大物，就有些困难了。
这里分享一个10分钟快速搭建 OAuth2.0 授权登录系统的方法，本文使用 github 作为示例。
由于各大运营商不同时间段出口带宽拥堵的问题，需要维护又连接不上服务器很恼火，整理一下通过代理访问SSH服务器的配置。
~/.ssh/config
Host hostname
ProxyCommand nc -x 127.0.0.1:1080 %h %p
命令行使用方法 ssh -o "ProxyCommand=nc -x 127.0.0.1:1080 %h %p" [email protected]
%UserProfile%\.ssh\config
Host hostname
ProxyCommand C:\Program Files\Git\mingw64\bin\connect.exe -S 127.0.0.1:1080 %h %p
批处理中要这样使用 ssh -o "ProxyCommand=C:\Program Files\Git\mingw64\bin\connect.exe -S 127.0.0.1:1080 %%h %%p" [email protected]
libstdc++.so.6: version `GLIBCXX_3.4.20' not found
错误信息是由于gcc版本低导致的，Centos通过yum无法升级，标准方案是手动编译安装，但是gcc编译少要半个小时，腾讯云的云盘可能要编译几个小时，不过有个取巧的办法，可以手动下载debian的二进制文件，下载地址 http://ftp.de.debian.org/debian/pool/main/g/gcc-*/ 根据需要选择 i386.deb 与 amd64.deb ，lib目录下放的是32位，lib64目录下是64位，如果是在其他奇怪的目录可以通过 file 命令查看原文件是32还是64位。
高能预警！！！
glibc是linux系统的核心部分，系统的很多文件就是基于这个程序编译，以下操作可能会导致未知的后果，仅限开发阶段，生产环境万万不可以。
然后在debian下解压出需要的文件
cd /usr/lib[ro lib64] chmod +x libstdc++.so.6.0.20 rm -f libstdc++.so.6 ln -s libstdc++.so.6.0.20 libstdc++.so.6
再检查一次看看
$ strings /usr/lib/libstdc++.so.6 | grep GLIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_3.4.20 GLIBCXX_DEBUG_MESSAGE_LENGTH
查看glibc版本
# 查看链接 ls -l /lib/libc.so.* # ldd 返回glibc版本 ldd --version
编译 glibc
curl -O http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz tar zxf glibc-2.18.tar.gz cd glibc-2.18/ mkdir build cd build/ ../configure --prefix=/usr make -j2 make install
首先这是一个历史遗留问题，这篇文章没有什么技术点，只是对刚接触 nginx 的同学解开一点可能遇到的困惑。
在诸多发行版中默认 nginx 安装后你会发现在 /etc/nginx 目录下有两个fastcgi配置文件，fastcgi_params 与 fastcgi.conf，运行diff后你会发现他们的区别只有一行，既fastcgi.conf多了一个fastcgi_params配置
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
SCRIPT_FILENAME 参数对PHP的运行是必不可少的，它的作用是告诉后端 PHP 应该执行哪个文件，但是由于历史原因他并没有被添加到 fastcgi_params 中。
在 nginx 0.6.x 时代，nginx 提供的默认配置中使用的是硬编码的方式
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;
fastcgi_pass backend;
}
这对迁移造成了不必要的麻烦，后来 nginx 建议大家使用 $document_root 来替代真实路径，大家慢慢开始使用它来替换之前的硬编码方式，但是很多年以后很多人依然在使用绝对路径，于是 nginx 在 0.8.30 中开始提供一个新的配置文件 fastcgi.conf来保持向后兼容，这样以来社区就可以推荐大家使用 fastcgi.conf 不需要在 location 中手动添加 SCRIPT_FILENAME。
现在我们引入这个文件可以使用下面的方式
location ~ \.php$ {
include fastcgi.conf;
fastcgi_pass backend;
}
如果你发现你的配置文件是
location ~ \.php$ {
include fastcgi_params;
SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass backend;
}
那也不用着急去修改自己的配置文件，无论使用这两种的哪一种，对 nginx 来说都是一样的。
Forsaken Mail 没有域名限制，只需要将自己的域名解析到已经部署的任意服务器。
1、服务器需要开启25端口
2、域名解析
# MX记录 xx.com MX 10 mx.xx.com # A记录 mx.xx.com A 服务器IP # A记录 mail.xx.com A 服务器IP
随着TLS 1.3问世，网络流量迈入了新时代，DoH和DoT都是将不同形式的数据包通过TLS 1.3加密，网络中可嗅探的数据变得越来越少，我前面发过一篇透过公共Wi-Fi 热点上网究竟安不安全，DNS加密后并且全程使用HTTPS协议，网关中依然会泄露访问的域名。
这里就需要普及一个名词叫做SNI，简单说因为服务器和客户端建立加密连接之前，客户端需要请求证书并明文发送主机名给服务器，服务器发送证书后，本地客户端再加以校验，这是因为通常同一个服务器端会部署多个域名服务，TLS握手发生在建立加密连接之前，如果直接扔过来一个加密包服务器端无法知道包的内容，也无法决定返回哪一个证书，所以网关仍然可以获取客户端访问的域名列表。
题外话：由于SNI的特性，通常NGINX服务器直接通过域名访问会泄露配置文件中的第一个证书，而有心者这可以通过证书内容获取很多信息，这个“漏洞”暂时还无法解决。
IETF在最新的草案中设计了一种新的加密SNI机制 Encrypted Server Name Indication（ESNI），ESNI要求DNS服务器负责随解析记录分发一个公钥，这样在TLS握手时，客户端就可以将通过加密DNS获取的公钥一并发送给服务器来直接建立加密连接，从而堵上了信息泄露的最后一个口子。
ESNI目前还在草案中，甚至还有很多可用性修复工作正在进行中，不过各大浏览器上已经在积极适配，Cloudflare在ESNI上特别积极，他们已经在1.1.1.1和所有Cloudflare节点部署ESNI完成。
目前浏览器支持方面比较悲观，仅Firefox 62+可以开启，Chrome开发组表示ESNI需要基于安全稳定的DNS服务，将会放在DoH适配之后，Cloudflare还煞有介事的制作了一个ESNI支持检测。
Firefox 开启 ESNI 方法
在地址栏输入about:config进入设置页面，修改network.trr.mode选项，设置为2优先使用DoH，设置为3则仅使用DoH。
修改network.trr.uri选项可以指定DoH服务器，默认是https://mozilla.cloudflare-dns.com/dns-query，我们也可以手动修改为https://dns.google.com/experimental或者https://1.0.0.1/dns-query。
也可以修改network.trr.resolvers值后，在选项 网络设置中配置服务器。
[{ "name": "Cloudflare", "url": "https://mozilla.cloudflare-dns.com/dns-query" },{ "name": "1.0.0.1", "url": "https://1.0.0.1/dns-query" },{ "name": "Google", "url": "https://dns.google/dns-query" },{ "name": "朽木", "url": "https://dns.xiumu.org/dns-query" }]
接下来点击修改network.security.esni.enabled即可开启ESNI。
国内的环境下说起DNS首先要解决的就是DNS抢答、运营商劫持，更有甚者v2ex曾有人爆料电信运营商内部出现高级内鬼劫持Cloudflare节点跳转菠菜网站，这里我整理一些常见的解决方案以及各种方案的利弊。
DNS是一项互联网基础服务，它通过几台互联网根服务器的数据库分发给各个子节点，将域名和IP地址进行对应，多数情况下使用TCP和UDP的53端口通讯。换句话说DNS负责告诉你访问的网络服务究竟对应的是哪家公司或机房的服务器，详细内容参见DNS记录类型列表，这里就不再赘述。那么问题来了如果它告诉你的答案是精心伪造的呢？
由于DNS规则制定在互联网早期，也根本没有考虑到会出现DNS缓存投毒攻击的情况，所以DNS服务器都是明文通讯，这就导致数据包可以在传输中受到干扰，且支持抢答，结果就导致了很多运营商或者组织在互联网上搭建了很多恶意节点分发虚假数据，干扰部分网络的正常访问、插播广告，而网络管理员和运营商劫持DNS插播广告是或拿来做数据分析本身是一块比较大的蛋糕，作为既得利益者更会阻碍DNS加密协议的推行（腹黑揣测）。