技术博客

今天突然发现Oracle云服务器登不上了，用密钥文件和密码都登陆被拒。第一反应是服务器被黑了，但是去控制台又没发现什么异常反应，昨天还用得好好的。原因先不深究，下面是解决过程：1、登陆到Oracle云服务控制台查看网络安全策略动过没，22号端口正常开放，没问题。2、重新下载ssh密钥文件来尝试登陆。登陆后依次进入【仪表板】>【实例】> 左侧资源列表的【Console connection】>【创建本地连接】然后在弹出框保存私有密钥就ok。然后发现用新下载的密钥也连不上，那说明不是密钥的问题。3、在上一步不下载密钥选择【启动cloud shell连接】，加载完黑窗口后用账户密码登陆进去看了下/etc/ssh/sshd_config配置文件也没啥问题。这里吐槽下Oracle的cloud shell真难用，不知道是网络问题还是浏览器问题上下左右键全按不动，Esc键无效导致我无法正常编辑配置文件。重启服务器依旧连不上，实在不行我只能祭出绝招：重装。4、先尝试重装ssh服务，因为cloud shell不受ssh服务影响所以我直接yum remove openssh-server，卸载完再yum install openssh-server安装服务。然后直接service sshd start开启服务，这次再去终端尝试ssh连接可行了。这里因为我选的操作系统是centos7并且用的root登陆，所以命令前面不用加sudo，启动服务也还可以用过渡的service命令。如果是ubuntu就要用apt替代yum了。问题解决，打完收工！

闲得蛋疼的人才会在Linux服务器上折腾图形界面，比如我。ubuntu上装GNOME远程桌面：1、准备联外网的ubuntu服务器一台，确保ssh服务正常。2、安装基本桌面sudo apt-get install gnome-session-flashback3、安装vnc服务sudo apt-get install tigervnc-standalone-server tigervnc-xorg-extension4、启动或关闭vnc服务vncserver :1 -localhost novncserver -kill :1上面的命令默认开启的5901，如果连不通需要查看防火墙和ecs服务器端口策略是否允许5901

朋友白嫖了一波甲骨文的服务器问我可以拿来干啥，我反手就上去弄了个ngrok穿透，然后朋友问可以看看油管视频不。好吧，最终还是走到了这步，下面是小火箭在centos下的搭建命令:准备工作：1台有外网的centos服务器，要装git和python以及python包管理工具pip，python版本在3以上。开始安装shadowsocks。

# yum install python-setuptools

# pip install shadowsocks

# vim /etc/shadowsocks.json

###### shadowsocks.json内容如下：

{

  "server": "0.0.0.0",

  "server_port": 服务端口,

  "local_address": "127.0.0.1",

  "local_port": 1080,

  "password": "你的密码",

  "timeout": 300,

  "method": "aes-256-cfb",

  "protocol_param": "同时在线人数，最小为2",

  "fast_open": false

}

###### 启动服务（centos下是ssserver，ubuntu下应该是ss-server）

# ssserver -c /etc/shadowsocks.json -d start

###### 关闭服务

# ssserver -c /etc/shadowsocks.json -d stop

###### 客户端，这里因为我用的是deepin就说deepin的，其他平台自行查询

# sudo apt install shadowsocks-qt5

免责声明：本教程自己学习测试用可以，不要以此牟利！私自兜售自建VPN违法！

ngrok挺好用的，有时候要远程办公又不想用国内的向日葵或者teamview就需要自建内网穿透。刚搭建的时候不知道怎么指定访问端口，每次重启服务访问端口都会变，比较头疼。下面是端口配置文件ngrok.cfg的内容:server_addr: "你的域名:服务占用端口"trust_host_root_certs: falsetunnels:   你定义的名称(例如my_ssh):     remote_port: 客户端访问端口(例如2222)     proto:       tcp: 穿透后访问的端口(例如ssh是22)   web:     subdomain: 域名前缀(例如www)     remote_port: 客户端访问端口     proto:        tcp: 穿透后访问的端口启动命令是你编译好的 ngrok -config ngrok.cfg start 你定义的名称(例如上面定义的my_ssh)

作为Linux的忠实用户，我觉得alias真心好用。每次要输入一大堆命令的时候就想写个bash脚本来运行，写了脚本下次用又要去找到文件路径再执行。当然脚本也可以放桌面，但是我是一个假装崇尚整洁的程序猿自然不想desktop乱糟糟的，这时候alias的作用就体现了。先找到.bashrc文件，一般都在家目录~/.bashrc，MacOs下是~/.bash_profile。vi ～/.bashrc，然后在里面加你想要的指令保存后source ~/.bashrc就ok了。比如我的pc一般www是去网站根目录，我一般这样写alias=cd /var/www/html这时候在命令行里面输入www回车就能直接去网站目录了。

下午写了个ini格式的配置文件下载，想着a=b,c=d这种参数既然可以用http_build_query把数字转成querystring格式自然也应该有函数可以转回来，避免去foreach处理。一查手册果然有parse_str函数可以用，一顿操作然后就上线了。结果没过一会儿同事就说这个东西有bug，我检查发现参数名都被改了，比如 [广东.佛山] 变成了 [广东_佛山]，测试的时候没用带点的参数所以没测出来。返回去仔细看手册果然官方文档写的清清楚楚，原话就是由于 PHP 的变量名不能带「点」和「空格」，所以它们会被转化成下划线。 用本函数带 result 参数，也会应用同样规则到数组的键名，怪我自己没看仔细文档就直接拿来用，一点都大意不得。

昨天读到一篇文章谈到了jwt的应用和安全，其中提到jwt令牌存在localStorage不安全，可以存到cookie会话里面，呃。。。
在互联网打了几年杂稍微谈谈我对jwt的理解吧。JWT全称json web tokens，是目前业界使用比较广泛的前后端分离用户认证解决方案。怎么广泛起来的呢，因为像海外谷歌、苹果这样的大厂都带头用，jwt这套方案又比较成熟规范。我最先接触jwt是在laravel框架上面，算是比较晚。由于项目需要完全的前后端分离采取了这套解决方案。
先说说早前使用的会话模式(session)：传统的用户授权一般是账号+密码登陆，这时候服务端需要记录一下用户的登陆信息用于区分用户，在网站上总不能张三买了东西算在李四头上。那么服务端一般会把当前登陆的用户信息存在session会话中，然后客户端会对应生成cookie信息，可以理解为下馆子点了菜的时候给发了号码牌。由于http协议是无序的，这时候用户无论做什么都会默认客户端(浏览器)都会带上cookie会话信息，一切安好。用户这个会话信息是不跨域的，不额外设置的话甚至不能跨目录，比如默认情况下你在www.zhangsan.com/aaa生成的会话不能在www.zhangsan.com/bbb用，更不能在www.lisi.com用。那么问题来了，业务上有多个网站zhangsan.com、game.zhangsan.com、lisi.com，几个网站之间要互通用户信息怎么办？早前我是见过一种奇葩的方案：A网站登陆后生成一个口令带在地址链接后面跳到B网站，然后B网站服务端去根据这个口令查询用户信息自动登陆，这样做的问题很多，也不安全。当前后端完全分离以后这种问题更突出，前端和后端可能不在同一个域名或者端口，甚至不在同一台服务器。随着业务的扩大后端也可能会搞集群分布式，后端可能不再是一台服务器一个ip，这时候再使用seesion会话这种认证方式就很费劲了，除了要解决跨域问题还要解决授权数据同步问题，与其花大力气改造不如换一种授权方式，JWT迎来了春天。
jwt授权基本思路也是用户登陆后生成一个用户的凭证(token口令)，用户每次和后端交互都带上这个口令，以此来识别用户。不同的是jwt的提倡只简单颁发一个token凭证，不参与其他逻辑，只要token签发时间没过期那么无论谁持有以及从哪里发起请求服务端都认可，除非服务端另外做逻辑。来看看jwt的基本结构：header(头部).payload(载荷).sign(签名)。其中header和payload是一般采用json格式再base64来的，sign签名部分一般是H256也就是HMACSHA256来的，当然也有像苹果这样用ES256的。生成的令牌一般存放在客户端localStorage，使用的时候在header里面带上Authorization: Bearer 这种方式，当然你硬要放在cookie里面也是能用的，但安全上并没有什么本质的不同，并不存在谁比谁更安全的问题。有人会说我一开调试模式就能看到token，拿到授权后我想干嘛干嘛毫无安全性。你想想session会话里面的cookie自然也能用这种方式拿来变造伪请求，一般的应对都是给授权信息一个过期时间，不然你仔细想想就算你买了个基因认证才能开的保险柜，在别人能进你屋里(打开你桌面和浏览器)柜子开着(token未失效)的情况下谁都能拿里面的东西不是吗？养成保护密码和人走了随时退出登陆状态的好习惯才能避免这种问题。当然保险柜也应该设置一个过期时间，开了很久都没人在里面拿东西的时候应该自动锁上，也就是token间隔一定时间不使用就自动失效。同时使用完全的前后端分离如果前后端不同域且客户端是浏览器的时候则需要服务端在服务中间件或代码里面开放跨域，也就是允许一些像Authorization、Token、POST、PUT等实际需要使用到的header请求头

jwt颁发的token通常情况下是不需要服务端存下来的，并且不推荐在里面放任何像用户信息之类的真实数据。因为像以前session会话这种方式实际上是要在服务器上的缓存目录中存放认证数据的，用户多了会占用不少的储存空间。这点上jwt解决了这个痛点，每次签发的token都让客户端存，且只校验有效性和是否过期。当然有时候也会在服务端存token来实现一些复杂或者特殊的业务和功能（比如在特定时间点要强制某个用户的token失效），但大多数情况下服务端都应该不存token，更不应该把token放在服务端session会话中。

说到底jwt也好session会话也好，产生和运用都是顺应时代发展和业务需求来的，并不用纠结于哪个好哪个更先进。安全是相对的，没有绝对的安全，只有不断地探索和进步。今天的jwt杂谈就分享到这里。

谷歌浏览器下载东西的时候发现会下载到历史文件，这个文件我已经改名更新了，然而却还是可以下载到。查了下资料发现谷歌最近有增大缓存来提升性能的新闻，下面是解决方案：
1、尽量给文件改名或者在文件后面加上参数，让浏览器知道这是个不同的文件。
2、尝试在服务端请求头中增加cache-controll = "no-store"，并修改文件有效时间max-age = 有效秒数

低配服务器实在拉胯，1M带宽每秒128k左右的速度加载一堆js实在太卡了。除了压缩我还想到延迟加载不是很重要的js，基本思路就是页面加载完了再去请求额外的js，下面是加载方案：
1、原生js创建节点再写入js资源标签。var js = document.creatElement('<script>');
js.src = 'test.js'; //要加载的js文件,也可以是url地址
document.body.appendChild(js);
2、用jquery的getScript方法。
$.getScript("要加载的js", function(){
  //加载完js后的回调
})

最近在迁移博客到新的地址，考虑到网站SEO不想用前后端完全分离再ajax请求渲染数据的模式。另一方面也不想用臃肿的框架于是自己琢磨手搓一个建议的博客。期间要操作html模板，于是不得不翻了翻DOMDocument。
下面是基本操作：
$dom = new DOMDocument(); //实例化dom
@$dom->loadHTML($htmlfile); //读取html文件到dom对象,@符号是抑制报错，自己玩这样做简单，正式的项目建议用更好的方式处理错误
$dom->getElementsByTagName('title'); //根据标签获取节点,跟js的dom操作方式类似
$elem = $dom->getElementById('testid'); //根据id获取节点
$elem->NodeValue = '文本内容'; //获取或者修改节点里面的文本
//appendChild 和 createElement不再赘述，这里吐槽下DOMDocument是没有js自带的dom操作方法好用的，对底层一些的东西没兴趣的话还是建议上smarty模板，当然前后端分离更酸爽。
官方文档点这里>>