在了解 CSRF 之前我们需要科普两个前提。首先是登录权限验证的方式有很多种，目前绝大多数网站采用的还是 session 会话任务的方式。session 机制简单的来说就是服务端使用一个键值对记录登录信息，同时在 cookie 中将 session id（即刚才说的键）存储到 cookie 中。另外我们又知道浏览器中 HTTP(s) 请求是会自动帮我们把 cookie 带上传给服务端的。这样在每次请求的时候通过 cookie 获取 session id，然后通过它在服务端获取登录信息即可完成用户权限的校验。
75CDN 是一个由奇舞团维护的静态资源托管平台，创立至今已经稳定运行了两年多的时间。近期我们增加了 ES Module 的支持，成为国内首个拥抱 ES Module 服务的静态资源库。
ES Module 是 ES6 中提出的规范，用于让 JavaScript 实现 import 导入模块的功能。其又细分为静态 import 和动态 import 两个特性，目前浏览器的支持情况如下：
| 浏览器 | 静态 import | 动态 import |
|---------------------|-------------|-------------|
| Chrome | 61+ | 63+ |
| Chrome For Android | 67+ | 67+ |
| Firefox | 60+ | 不支持 |
| Firefox For Android | 60+ | 不支持 |
| Safari | 10.1+ | 11.1+ |
| iOS Safari | 10.3 | 11.2+ |
| Edge | 16+ | 不支持 |
注： 数据来源于 CanIUse
大家使用的服务中或多或少是不是都有以下的功能：
简单的来说就是通过 URL 抓取其它服务器上数据然后做对应的操作的功能。以 ThinkJS 代码为例，我们的实现方法大概如下：
const request = require('request-promise-native');
module.exports = class extends think.Controller {
async indexAction() {
const { url } = this.get();
const ret = await request.get(url);
// 这里是处理抓取数据的逻辑
// ...
this.ctx.body = ret;
}
}
本来是个不错的功能，但是当用户输入一个服务器可访问的内网地址，这个情况下它就会把内网的内容抓取出来展现给外网的用户。大多数公司会在内网中放置一些与公司相关的资料和关键数据，如果应用程序对用户提供的URL和远端服务器返回的信息没有进行合适的验证和过滤，就可能存在这种服务端请求伪造的缺陷，即 Server-Side Request Forgery，简称 SSRF。
在小程序开发过程中，代码提交突然变成了一件非常头疼的事情。因为小程序的开发、编译、预览到最后的上传发布过程中，任何一步其实都和 Git 没有任何关系。所以之前自己一个人开发的时候，经常性的就忘记了 commit 代码，亦或是 commit 了但是没有对远端进行 push 操作。一个人开发的时候还好，多个人开发的时候再是这种操作习惯可就要把人坑惨了。
另外还有一个问题是，小程序的发布对 Git 没有强相关，所以对代码分支的要求不高。一般说来，日常的 Web 开发中，我们都是在 dev 或者 feature/xxx 分支中进行开发，test 分支进行测试，最后 master 分支合并后上线。能够严格的执行这个过程的最重要的原因是因为我们的发布系统只支持从主分支上拉取代码，强制让大家养成了良好的习惯。但是小程序中没有这种强相关，所以会经常导致主分支不是最新的版本，而可能是某个其它分支才是线上最新代码。长久以往下去，可能没有同学能够清楚最新的代码是在哪个分支了，一不小心就把分支给删除了也有可能。
代码调试按照调试方式大致分为日志（Log）和断点（Breakpoint）两种办法。其中日志就是手动的在代码中增加日志打印获取过程信息来判断问题。这种方法的好处是调试简单，一个对业务熟练的工程师通过线上良好的日志记录可以非常快的发现业务问题。但是它的缺点也非常明显，获取的内容比较单一，动态调试需要不断的在业务中增加日志打印代码。
于是乎断点调试出现了。断点调试类似于中医的望闻问切，我们通过在需要观察的点打上断点就能详细的获取到程序运行到该点时的所有上下文，并利用单步调试逐一观察程序运行状况，准确判断出问题的地方。另外利用 Chrome DevTool 我们也可以随时对线上业务进行调试，可以说是非常方便了。
公司内部使用的是 Gitlab 仓库套件管理项目代码，之前把玩过的 Drone CI 是可以很好的支持 Gitlab 的，前提是需要在 Gitlab 中申请一个管理员权限的密钥方便其读取项目目录并设置 Webhook 等操作。而公司的 Gitlab 仓库权限管理很严格，我暂时还没有权限申请这个就只能放弃了。最近他们使用 Gitlab 8 （不要问我为什么是这么早的版本毕竟我们一直都在用7的）搭建了一个新的仓库，自带支持了 Gitlab CI 的功能，于是就拿来试了下。
Gitlab CI 整个流程和 Drone 以及流行的 Travis CI 都是比较类似的，通过在项目中添加一个 .gitlab-ci.yml 的配置文件，配置文件中描述构建流水线来执行任务。有的同学说为什么不试试 Jenkins，那 Jenkins 的配置那么的复杂反正我是拒绝的。
话说最近真是流年不利，感觉各种BUG犹如天灾一样全部冒出来了，这不昨天又解了一个非常无语的问题，大概是关于换行和正则的臭虫，下面给大家吐槽一下。
昨天同事反馈某个页面的数据没有正常显示，最开始我还以为是接口没有返回数据，结果看了下请求发现接口有正常的数据呀。没办法就一路反查回去，最后查到居然代码里接口请求抛错了？！因为定义了 Promise 的 catch 流程，所以也没有把错误抛出来。因为之前这个页面都是正常的，很久都没有改动所以我第一反应是这个数据异常了，查了半天的数据格式问题。可是问题就在于明明看到数据是正常的呀，服务端没有报错，接口数据也是可以正常解析的。最后我突然想起来，我们的接口是 JSONP 的会不会是 JSONP 功能挂了？查了一下果然是这样。
前段时间我开源了一个叫 Animaris 的项目，这个项目是使用 ThinkJS + MongoDB + React + Antd 开发的移动端 WebView 接口文档系统。平常大家见到的接口文档无非就是 HTTP API 接口文档，要么就是框架/库提供的接口方法文档。对于这种 WebView 的接口提供文档基本上没有。借着业务的需求我做了这么一个项目，用来解决以下两个问题：
如果有相关需求的同学也欢迎使用，感兴趣的同学也欢迎 star。咳咳，回到本文的重点，项目开发的差不多的时候我就准备给它设计一款 LOGO 了，以下是成品效果图。虽然我没有学过绘画没有很好的设计功底，但是我相信简单的形状也能发挥不错的效果，那么我就给大家讲讲我是如何设计这款 LOGO 的。另外由于动画效果有兼容问题，最好使用 Chrome 等现代浏览器查看本文哦~
小程序以免安装用完即走的特性自发布初就很火，即使是现在也是热度不减。小程序虽然是一个 HTML5，但是通过限制开发者的写法，提供一套自定义的组件以及写法，并且将一部分耗费性能的组件使用客户端渲染来极大的提高网页的性能。
前段时间我们也进行了小程序的开发。由于是接手的项目，这个项目之前是没有使用框架，直接使用原生小程序开发的，开发过程中就发现有很多不方便的地方。例如 NPM, Promise 组件化等。最后我对 wepy, tinajs, labrador, mpvue 等多个框架进行了调研，最后决定使用 tinajs 对项目进行重构。选择 tinajs 的原因是它是基于小程序的语法，并没有多大的改造，学习成本非常低。同时它的渐进式概念让我能够循序渐进的接入框架，而不是一下子就要把它的所有概念都要学习下来，这对当时工期比较紧张的我来说是比较重要的。当然还有一个更重要的原因是，它的源码非常的简单，即使是出了问题我也能快速定位出来。
不过即使是选择了一套正确的框架，碰到坑的情况也是在所难免的，小程序更甚。下面我就我这段时间碰到的一些比较经典的问题来说一下我碰到的一些问题。
其实这个话题很简单，不是很想写这篇文章。不过的确还是有很多朋友在打包构建部署上存在一些问题，恰巧最近使用 Docker 部署了几个 ThinkJS 相关的项目，所以还是拿出来说说吧。需要提前说明的是本文并不是 Docker 的基础教程，默认大家都是了解 Docker 的。然后我会分享一下我觉得 ThinkJS 项目构建和部署过程中可能需要注意的点，我们先说说如何构建镜像，然后再说一下可能出现的问题。
