Ubuntu-C/C++编译简单调试 2019-01-21

起步

初学C++,需要一个代码编辑器,和一个能编译c/cpp文件的编译器,以及能进行简单的调试即可。

安装整合包

1
2
sudo apt-get update
sudo apt-get install build-essential

build-essential 中包含依赖了所需要的编译器(gcc、g++)调试工具(gdb)。

打开任意IDE或代码编辑器,这里用的是webstorm, 虽然JetBrains已经有Clion这款C++ IDE了,但我这边不想再多装一个软件。

新建一个main.cpp文件,写段简单的代码。 并且打开终端或编辑器自带的Terminal,输入命令:

1
g++ main.cpp -o main.out -g

更多 >>

Chrome-Ajax读取JSON报错 2018-12-19

因为一些需求需要读取本地的JSON文件内的数据,但发现在本地浏览器环境下使用Ajax、getJSON等方法读取目录下的json文件时,Chrome控制台报了以下错误:

Access to XMLHttpRequest at ‘file:///C:/Users/Administrator/Desktop/test/1.json’ from origin ‘null’ has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

可以看到访问桌面下的 1.json 文件的请求被阻止了,在后面给出了Chrome下支持的几种跨域请求协议格式,分别是http, data, chrome, chrome-extension, https,而本地桌面文件的访问协议是file开头的,Chrome下并不支持这种file协议。

解决方案:

1.将代码部署到服务器环境下运行(脱离本地环境)
2.JSONP

主要记录下第二种JSONP方法的具体实现方法:
在HTML文件中通过 <script> 标签将JSON文件引入进来,如下:

1
<script src="1.json"></script>

修改下1.json文件中的内容,制定一个函数,将原来的json数据作为函数参数,同时调用函数:

1
2
3
4
5
6
7
8
9
10
11
12
getData({
"news": [
{
"title": "新闻标题1",
"time": "2018-12-19"
},
{
"title": "新闻标题1",
"time": "2018-12-19"
}
]
});

更多 >>

定制属于自己的人生游戏 2018-12-01

​之前因为拖延症以及爱折腾的原因换过各种各样的待办APP,其中比较有意思的是一款名叫Playtask的移动应用,通过把日常中的任务、待办事项变成游戏中的任务、副本来刺激用户完成任务获得游戏金币,再通过游戏金币购买自己的欲望,这样满足的欲望不会使自己产生罪恶感,因为毕竟金币是自己完成任务挣来的,也限制了自己的很多的弊端行为,比如大手大脚的花钱买衣服等等。

​那么,如果把人生真正的玩成一个游戏,会是怎样的? 毕竟Playtask太简单了。于是我尝试通过写文字的方法来定制自己的人生游戏。文字的灵活度让这个游戏可定制度非常高,想象力发挥到极致。

​首先,由于我这边写字是用的markdown,,得先找到一款支持markdown的编辑器或笔记类应用,这款编辑器最好是支持多平台的(有道云笔记,simplenote…),我一天的绝大部分时间都要面对电脑,所以只找了PC端的一个本地编辑器Typora,再通过dropbox备份到云端。

​打开编辑器,新建MD文件:

游戏设定.md

​先确定下游戏的世界观、例如下面:

古老的王的大陆,人们愉快的在这里生活着,通过辛勤劳作挣取报酬,但在这篇大陆上,并不仅存在着人类,还有各种异界怪物,动物以及传说中存在的上古神明,怪物肆意的破坏着人类的栖息地,残杀人类,抢夺人类的资…….

​这个世界的勇者被称为探险家,那么探险家的等级如下(参考了哥杀):

职耀名称 等级
白瓷 1~5
青铜 6~10
矢银 11~20
黄金 21~30
白金 31~40
钻石 41~60
黑曜石 61~80
星辉 81~110
石灵 111~180
传说 181~

游戏拥有商店,也就得先确定下货币以及换算。

更多 >>

前端安全 2018-09-25

( 本文长期更新 )

CSRF

跨站请求伪造(英语:Cross-site request forgery),也被称为 one-click attack 或者 session riding,通常缩写为 CSRF 或者 XSRF, 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨網站指令碼(XSS)相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。

攻击原理

用户A登陆某一网站(例如豆瓣),登陆成功后该用户浏览器客户端存留Cookie记录.
该网站有条删除用户日记的接口地址:http://www.douban.com/del/article/1
攻击者利用各种手段(微信发短网址链接等等)引诱用户A进入恶意网址。 恶意网址的Html内容如下:

1
<img src="http:www.douban.com/del/article/1"/>

用户A在毫不知情的情况下请求了http:www.douban.com/del/article/1这个接口,由于他不久前登陆过豆瓣,客户端存留登陆成功的Cookie,就这样莫名的删除了自己的一篇日记,CSRF利用的就是这点,浏览器只能识别是否是该用户访问,却不能识别是否是该用户 本人意愿访问。

应对策略

后端处理 (Referer)

客户端向服务器发送请求时,Http请求头内存在一个Referer属性,属性值就是发起该次请求的域名。后端在代码里关键操作部分进行判断,如果Referer的值等于已知的域名(自家域名)则放行继续操作,否则打回。 这种办法有局限性,因为不同浏览器对Referer这个实现可能会有差异,也不排除有攻击者直接攻击浏览器篡改Referer的可能。

前后端配合处理(Token)

后端在用户登陆成功时分配给该用户一个随机生成的Token值,存在session内,同时把这个Token值返回给前端,前端可以把这个值存到cookie内或者其他本地存储,每次向服务器发起请求时把Token值作为参数一起传给后端,后端判断传过来的token是否和session中的token一致,一致则放行,否则打回。由于CSRF攻击者只能伪造用户的Cookie来骗过浏览器,但是他并不能得到Cookie中的具体值(例如Token值),所以这样的恶意请求会被后端打回,有效的防止了CSRF攻击。

更多 >>

Hello 2017-11-01

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1
$ hexo new "My New Post"

More info: Writing

Run server

1
$ hexo server

More info: Server

Generate static files

1
$ hexo generate
更多 >>
    1