⑴ 前端登陆获取保存token再添加到请求头中
登陆获取token保存在本地，在请求头添加参数
登陆：
$.ajax({
url : 'http://119.254.155.151:8768/yq/dy/login',// 获取自己系统后台用户信息接口
data :data,
type : "post",
dataType: "json",
success : function(data) {
const token = data.data.token
window.localStorage.setItem('yq_token', token)
}
}）
内部页面添加请求头：
var userToken = window.localStorage.getItem("yq_token");
$.ajax({
headers: {
"token":userToken//此处放置请求到的用户token
},
type: "get",
url: "http://119.254.155.151:8768/yq/important/data?schemeId=247248",//请求url
contentType: "application/x-www-form-urlencoded",
success: (data) => {
}
}）
⑵ TokenX.Group发起人赵大伟：研判Token经济系统的7个层面
在Token经济里，最重要的是社会企业家和通证经济设计师。
上周六，区块链捕手举办了第一期捕手沙龙，本次沙龙邀请到四位 Token 经济
的行业专家围绕着“如何设计一个 Token 经济系统”分享自己的实践或研究心
得，本文是沙龙系列分享内容的第二篇，希望能对关注 Token 经济的你有所启
发。
本文是赵大伟的分享内容。赵大伟是区块链项目TokenX.Group发起人，区块链早
期项目投资人，区块链与Token 经济学研究者，和君咨询前合伙人，畅销书《互
联网思维独孤九剑》作者。
现在很多人都去做区块链和发币了，但不知道大家有没有想过，区块链是否真的
代表着未来？如果是昙花一现，我们是不是成了笑话？如果不是昙花一现，背后
的支撑逻辑在哪儿？我尝试着回答下这个问题。
人类历史上进化的根本动力是什么？教科书是这么讲的，人类历史不断前进的动
力是生产关系和生产力不可调和的矛盾，后者翻译过来就是财富创造机制。因
此，
那么财富的本质是什么？财富的本质是一种权利，一种可支配资产和劳动的权
利，只不过它在不同的时代具有不同的表现形式，资产是财富的表现形式，货币
是财富的表达符号。在农业时代，财富体现为食物、作物，在工业时代，财富体
现为设备、厂房，那么区块链时代呢？
对于Token，不同的人会赋予不同的权益，如果想让这个Token更有价值，一定要
把这个组织获得的利益尽可能多地投射进去。
所以我认为，
�
首先它要有使用权的属性，
当它的专属使用权放在价值网络当中兑换成通用使用权时，它的本质属性就是货
币了；当这种使用权根据总量恒定逻辑，把股权投射进来，它就具有了股权的属
性。这种“具有穿透效应”的Token，是一种超越股权、债权的资产。
我认为只有这样设计的Token才更加具备激励价值，
这样的逻辑是什么？消费者和投资者互相接盘，这在原来很难
做到，但是在Token时代就可以做到，这是更为柔性的权利，这也是Token的魅力
所在。
接下来我来讲讲区块链世界的第一个Token：比特币，通过我们最熟悉的比特
币，来看一个Token经济系统的逻辑。
让我们先来回顾一下纸币的发展历史。
现代意义上的纸币起始于1696年成立的英格兰股份制银行。在英法之间发生“九
年战争”期间，英国王室入不敷出，不断向富人们借钱，又无法及时偿还，于是
英国王室就自行印制政府债券，用这些政府债券来抵押贷款，承诺债券的利息，
还承诺这些债券可以用于交税。
但英国的富人们觉得这其实是在让富人们为政府的战争和赤字承担风险和责任，
他们认为这些风险应该让全体国民共同承担，于是集体成立了英格兰银行，由
1208位股东共同出资，再由该银行将股东们集资的120万英镑借给政府，条件是
允许这家银行发行的债券作为正式的货币流通，取代或部分取代原来金银货币的
流通。
不再用真金白银来铸币，而是用白纸来印制货币，这意味着什么？在硬通货币时
代，铸币者充其量可以通过减少金银币的成色来取巧，从中谋取“铸币税”。如
今政府通过印钞来可以疯狂攫取“铸币税”，只要政府打个借条，银行就可以开
始印钱，印了钱就可以买东西。
此时的货币，支撑其价值的不再是财富，而是政府的信用。只要大家相信政府的
债券货币（借条）值钱，它就值钱。尽管政府可能打了太多的借条，并因此不断
地将真实的财富往政府手里集中，而百姓手里的债券货币只不过是一种财富符号
而已。
这实际上这是一种剥削制度，怎么体现呢？
第一个案例，比如说政府要发行纸币，A银行因为其是银行所以可以先得到这笔
货币，然后其以高于央行的贷款利率贷给贷款人。假如此时央行的贷款利率是
1%，那么A银行一定会以大于1%的利率贷款给实际贷款人，假设为3%，此时实际
贷款的利率就是4%。
商人以追求利润为目的，那么当他把这笔贷款投资到商品生产后，其商品销售价
格自然要把这4%算在内，于是位于链条终端的老百姓必须为这4%的贷款利率买
单。
第二个案例，假设有一个小岛，你用1000元可以买到这个岛上所有的商品和服
务，此时每个单位货币对应的商品服务是一定的，如果这个岛上的政府再增发一
千元货币，相当于每个人手上持有的货币就贬值了，原来的10块钱可以买到10块
钱的东西，但现在1只能买到5块钱的东西，这意味着购买力下降了，那么谁得到
了好处？
这也是一种剥削模型，这个模型被当时的英国政府无限复制和放大，每占领一个
殖民地，英国就立刻把英镑的货币制度导进去，不断印钱，把当地的财富源源不
断地转移到英国政府。英国政府为什么成了后来的“日不落帝国”？从根本上
讲，债券货币功不可没。
两次世界大战之后，美元取代昔日的英镑成为了世界货币，这意味着美国政府开
始打借条印发美元这种债券货币了。
布雷顿森林体系建立之初，为了确立美元的霸权，美国政府曾经对全世界做出承
诺，把各国的货币锁定美元，而美元锁定黄金，即每35美元兑换1盎司黄金。
但是情况没有那么简单。美国在二战之后愚蠢地接连卷入朝鲜战争和越南战争，
这两场战争使美国耗费巨大财力，尤其是越南战争期间，美国差不多花费了八千
亿美元的军费。当时每35美元对应1盎司黄金，美金流失也意味着黄金要流失
的。
当时法国的戴高乐总统说，我不再相信美元了，要求把黄金换回来。于是其它国
家相继效仿法国把黄金换回来，这样逼得美国当时无路可走。最后在1971年8月
15日，时任美国总统尼克松宣布关闭黄金窗口，美元与黄金脱钩。
从这一天开始，我们进入到一个真正的纸币时代，美元的背后不再有贵金属，它
完全以美国政府的信用作为支撑并从全世界获利。简单地说，美国人可以用印刷
一张绿纸的方式从全世界获得实物财富。人类历史上从来没有过这样的事情。
人类历史上获得财富的方式很多，要么用货币交换，要么用黄金或者白银交换，
再要么用战争的方式去掠夺，但是战争的成本非常巨大。
2008年的美国金融危机再次冲击了全球经济，仰仗着美元的全球购买力和融资能
力，美国以极低的成本刺激经济，很快从金融危机的阴霾中复苏，但全球经济至
今没有回到2008年前的增长水平。
比特币就是在这个背景下诞生的。比特币的创世区块里写着当天的《泰晤士报》
头版标题——“The Times03/Jan/2009 ，Chancellor on brink of second
loutfor banks”（2009年1月，财政大臣在对银行进行第二次救助的边
缘）。
如果要设计一个生态系统，这个生态的使命是什么？帮助什么人群解决了什么问
题？这是生态最根本、最基础的问题。当这些基础问题明确了，生态系统的设计
就容易多了.
在传统的货币制度中，黄金作为实物货币，流通成本较高（分割麻烦，携带不
便），且容易被暴力机关控制，而比特币在效仿黄金的逻辑设定的同时，
同时，比特币作为一种点对点的电子现金系统，不需要中心化的机构去做信用背
书，所有交易登记让所有参与网络的矿工去进行。比特币的设计还包括怎样防止
伪造、依据什么样的逻辑和规则去激励等等，它目前的共识机制还比较简单，后
面还会有越来越多的共识机制。
比特币是区块链世界的第一个Token，这样的一套经济系统的设计值得所有区块
链项目参考。
目前市场上有两个项目，它们在还没有Token的时候，就已经做了相应的事情，
而且成绩不错。
第一个是趣头条，它在2016年6月上线，距今不到两年。这个项目是我老妈推荐
给我的，很多趣头条的用户都是四、五线的城市居民，他们为什么愿意看？因为
他们看完一篇文章后可以获得50个金币，你把文章转发到朋友圈，如果有人通过
这篇文章注册你也会获得50个金币，同时趣头条还有一个叫做收徒弟的裂变机
制，当你下一级的徒弟看文章时，你也会有对应的金币激励，而金币是可以兑换
成现金的。
通过这些金币激励方式，趣头条获得了非常成功的成绩，2017年年底数据显示，
趣头条APP注册用户超过七千万，每月活跃用户达到三千万，日活跃用户达到一
千万，现在还准备赴美IPO。
另外一个项目是昆山服装企业，每年有几个亿的营收。这个企业内部有一个米票
系统，这个米票系统会面向内部员工和上下游合作伙伴发行，很多的消费者和代
理商也持有米票，米票代表着分红权，每年公司会拿出一定的利润按照米票持有
金额进行分红。
那怎样的行为可以获得米票呢？比如某部门要组织一次培训活动，但是内部资源
不够，该部分可以在拿一百个米票悬赏，哪个部门愿意提供一个场地，哪个部门
愿意提供讲师，那么一百个米票就给谁。通过这个方式，这个企业的业绩几年时
间翻了好多倍。在这个案例汇总，其实米票也可看做一个Token，唯一的区别就
是流动能力没有Token强。
以上两个例子就向我们证明：
在设计一个Token经济系统前，我们首先要思考自己想解决什么问题、解决多大
的问题？对这个问题的思考不能局限于商业的视角，更要用社会的视角去看待。
基于一些宏大的愿景，我认为一共有7个层次的问题需要思考：
1. 解决什么问题——解决多大的问题，就能成就多大的事业（不局限于商
业视角，社会企业家）；
2. 生态演化路径——业务成长逻辑，有哪些关键项目支撑；
3. 参与角色梳理——有哪些参与者：生产者、消费者、投资者、传播者；
4. 定义协作规则——各角色之间如何展开协作；
5. 贡献度设定——不同参与者的贡献权重，在不同时间轴上的分布；
6. 多层次激励机制——参与者的回报不局限于物质利益，根据需要设计多
层次回报体系（可以设置不同的Token）；
7. 激励兑现方式——如何保障激励可以不折不扣被兑现。
为什么是多层次激励机制呢？因为不是所有人的动力都是利益层面的激励。
比如有些人看中金钱，有些人看中名望，不同的层次的汇报可以体现为不同
的Token。
举个例子，假设一个区块链媒体想发行Token并用Token的方式去运作，按照我们
刚才讲的7层次，大家可以思考下它解决了哪些问题？比原来的模式好多少？我
这里不完全展开，只讲讲重点。
如果这个区块链媒体要给读者发Token，读者读得越多，获得的Token就越多。那
请问这些读者是为了领Token才来看这个媒体的吗？他来这里的第一目的是什
么？媒体能帮到读者什么？比如说读者想通过区块链媒体提升对区块链盲区的认
知，那一定需要有认知的人给这个媒体做贡献，才能满足读者的需求。
Token的绝大部分应该给这些内容的创造者，很少的部分才能给到读者，这是权
重的问题，如果权重设计偏了，很可能这个生态就成长不起来。
⑶ vue+flask前后端分离解决csrf token问题
是攻击者通过跨站请求，以合法的用户身份进行非法操作（如转账或发帖等）。CSRF的原理是利用浏览器的Cookie或服务器的Session，盗取用户身份
防范CSRF的主要手段是识别请求者的身份，通过在表单中添加令牌（token）。
前后端分离实现过程：
后端写入令牌
为了能够让所有的视图函数受到 CSRF 保护，需要开启 CsrfProtect 模块:
生成token值并利用请求钩子设置cookie，然后前端就能获取到cookie值
在前端请求时带上 csrf_token 值
根据登录和注册的业务逻辑，当前采用的是 ajax 请求
所以在提交登录或者注册请求时，需要在请求头中添加 X-CSRFToken 的键值对
原文链接： https://blog.csdn.net/paul0926/article/details/94544048
⑷ XLNet 详解
BERT 训练时将部分单词 mask 起来，使模型能够利用句子双向的信息，在很多 NLU 任务上取得很好的效果。但是 BERT 忽略了 mask 单词之间的关系，且微调过程与预训练过程不一致 (微调时没有 mask 的单词)。XLNet 采用了 PLM (Permutation Language Model) ，将句子随机排列，然后用自回归的方法训练，从而获得双向信息并且可以学习 token 之间的依赖关系。另外 XLNet 使用了 Transformer-XL，使用了更广阔的上下文信息。
XLNet 论文中首先提出了一种比较有意思的观点，将当前预训练模型分为了两类 AR (Auto Regression，自回归) 和 AE (Auto Encoder，自编码器)。
GPT 就是一种 AR 方法，不断地使用当前得到的信息预测下一个输出 (自回归)。而 BERT 是一种 AE 方法，将输入句子的某些单词 mask 掉，然后再通过 BERT 还原数据，这一过程类似去噪自编码器 (Denoising AutoEncoder，DAE)。不熟悉 GPT 和 BERT 的童鞋可以参考前面的文章， 《OpenAI GPT 和 GPT2 模型详解》 和 《彻底理解 Google BERT 模型》 。
AR 的方法可以更好地学习 token 之间的依赖关系，而 AE 的方法可以更好地利用深层的双向信息。因此 XLNet 希望将 AR 和 AE 两种方法的优点结合起来，XLNet 使用了 Permutation Language Model (PLM) 实现这一目的。
Permutation 指排列组合的意思，XLNet 将句子中的 token 随机排列，然后采用 AR 的方式预测末尾的几个 token。这样一来，在预测 token 的时候就可以同时利用该 token 双向的信息，并且能学到 token 间的依赖，如下图所示。
接下来介绍 XLNet 中的实现细节，其中 XLNet 为了实现 PLM，提出了 Two-Stream Self-Attention 和 Partial Prediction。另外 XLNet 还使用了 Transformer-XL 中的 Segment Recurrence Mechanism 和 Relative Positional Encoding，不熟悉 Transformer-XL 的童鞋可以参考前面的文章， 《Transformer-XL 语言模型》 。
PLM (Permutation Language Model) 是 XLNet 的核心思想，首先将句子的 token 随机排列，然后采用 AR 的方式预测句子末尾的单词，这样 XLNet 即可同时拥有 AE 和 AR 的优势。
XLNet 中通过 Attention Mask 实现 PLM，而无需真正修改句子 token 的顺序。 例如原来的句子是 [1,2,3,4]，如果随机生成的序列时 [3,2,4,1]，则输入到 XLNet 的句子仍然是 [1,2,3,4]，但是掩码需要修改成下图。
图中的掩码矩阵，红色表示不遮掩，白色表示遮掩。第 1 行表示 token 1 的掩码，可以看到，1 是句子的最后一个 token，因此可以看到之前的所有 token (3,2,4)。3 是句子的第一个 token，看不到句子的任何信息，因此第 3 行都是白色的 (表示遮掩)。
Two-Stream 概念
XLNet 打乱了句子的顺序，这时在预测的时候 token 的位置信息会非常重要，同时在预测的时候也必须将 token 的内容信息遮掩起来 (否则输入包含了要预测的内容信息，模型就无法学到知识)。 也就是说 XLNet 需要看到 token 的位置信息，但是又不能看到 token 的内容信息 ，因此 XLNet 采用了两个 Stream 实现这一目的：
Query Stream 计算
Query Stream 用 g 表示，Content Stream 用 h 表示，使用 Query Stream 对要预测的位置进行预测的时候，Q (Query) 向量是用 g 计算得到的，包含该位置的位置信息，而 K (Key) 和 V (Value) 是用 h 计算的，包含其他 token 的内容信息。下图展示了如何通过当前层的 g 计算下一层 g 的过程，图中的排列是 [3,2,4,1]，计算的 token 是 1。
可以看到在计算 token 1 的 Q 向量时，只使用了 token 1 的 Query Stream g ，即模型只得到 token 1 的位置信息。而向量 K，V 使用 token 3, 2, 4 进行计算，所以模型可以得到 token 3, 2, 4 的内容信息。因为 token 1 是排列 [3,2,4,1] 的最后一位。这一个过程的掩码矩阵和上一节的是一样的 ，对角线上都为白色，即遮掩当前预测位置的内容信息 h 。
Content Stream 计算
Content Stream 包含了 token 的内容信息，因为 XLNet 的层数很多，需要将 token 的内容传递到下一层。这一层的 Q, K, V 都是利用 h 计算的。Content Stream 的计算如下图所示。
可以看到，在计算下一层的 h1 时，也会利用 token 1 当前的内容信息，这样就可以将 token 的内容传递到下一层，但是注意 XLNet 在预测时只是用 g (Query Stream)。计算 Content Stream 时候的掩码矩阵如下图所示。
和 Query Stream 的掩码矩阵区别在于对角线，Content Stream 不遮掩对角线，使得当前 token 的信息可以传递到下一层。
Query Stream 和 Content Stream 组合
XLNet 将 Query Stream 和 Content Stream 组合在一起，如下图所示。
图中最下面的一层是输入层，其中 e(x) 是单词的词向量，表示输入的 Content Stream，而 w 表示输入的位置信息，即 Query Stream。
XLNet 将句子重新排列，然后根据排列后的顺序使用 AR 方式预测，但是由于句子是随机排列的，会导致优化比较困难且收敛速度慢。因此 XLNet 采用了 Partial Prediction (部分预测) 的方式进行训练，对于排列后的句子，只预测句子末尾的 1/K 个 token。
例如 K=4，就是只预测最后 1/4 的 token。给定句子 [1,2,3,4,5,6,7,8] 和一种随机排列 [2,8,3,4,5,1,7,6]，则只预测 7 和 6。论文中训练 XLNet-Large 时使用的 K 为 6，大约是预测末尾 14.3% 的 token。
XLNet 使用了 Transformer-XL 中的 Segment Recurrence Mechanism (段循环) 和 Relative Positional Encoding (相对位置编码) 进行优化。
Segment Recurrence Mechanism 段循环的机制会将上一段文本输出的信息保存下来，用于当前文本的计算，使模型可以拥有更广阔的上下文信息。
在引入上一段信息后，可能会有两个 token 拥有相同的位置信息，例如上一段的第一个单词和当前段的第一个单词位置信息都是一样的。因此 Transformer-XL 采用了 Relative Positional Encoding (相对位置编码) ，不使用固定的位置，而是采用单词之间的相对位置进行编码。在之前的文章《Transformer-XL 语言模型》中有比较详细的介绍，感兴趣的童鞋可以参考一下。
XLNet 使用了 Transformer-XL 后如下图所示。 mem 表示的就是前一个 XLNet 段的内容信息，而 XLNet 中输入的 Query Stream 为 w，保存位置信息，采用的是 Relative Positional Encoding。
XLNet 希望像 BERT 一样采用 [A, SEP, B, SEP, CLS] 的形式处理句子任务，在 BERT 中有两个表征向量 EA 和 EB 分别表示句子 A 和 B。但是 XLNet 采用 Transformer-XL 的段循环机制后会出现问题，两个段都有句子 A 和 B，则两个句子 A 属于不同的段，但是却会有相同的 Segment 向量。
XLNet 提出了 Relative Segment Encodings，对于每一个 attention head 都添加 3 个可训练的向量 s+ , s- , b ，然后利用以下公式计算 attention score。
其中 q 就是 Query 向量，这个计算得到的 attention score 会加到原来的 attention score 上，再计算 softmax。Relative Segment Encodings 加上了一个偏置向量 b ，同时 Relative Segment Encodings 也可以用于一些超过两段输入句子的任务上。
XLNet 的核心思想是 PLM，排列原来的句子，然后预测末尾的单词。这样可以学习到单词之间的依赖关系，而且可以利用 token 前后向的信息。
XLNet PLM 的实现需要用到 Two-Stream Self-Attention，包含两个 Stream，Query Stream 用于预测，只包含当前位置的位置信息。而 Content Stream 保存了 token 的内容。
XLNet 还使用了 Transformer-XL 的优化方式。
XLNet: Generalized Autoregressive Pretraining for Language Understanding
⑸ csrf_token的了解
django中写form表单时csrf_token的作用： https://blog.csdn.net/up1012/article/details/81032368
Django下的CSRF预防机制
https://www.cnblogs.com/freely/p/6928822.html
CSRF预防机制
CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。
token防御的整体思路是：
第一步：后端随机产生一个token，把这个token保存在SESSION状态中；同时，后端把这个token交给前端页面；
第二步：下次前端需要发起请求（比如发帖）的时候把这个token加入到请求数据或者头信息中，一起传给后端；
第三步：后端校验前端请求带过来的token和SESSION里的token是否一致；
1、Django下的CSRF预防机制
django 第一次响应来自某个客户端的请求时，会在服务器端随机生成一个 token，把这个 token 放在 cookie 里。然后每次 POST 请求都会带上这个 token，
这样就能避免被 CSRF 攻击。
在 templete 中, 为每个 POST form 增加一个 {% csrf_token %} tag. 如下:
在返回的 HTTP 响应的 cookie 里，django 会为你添加一个 csrftoken 字段，其值为一个自动生成的 token
在所有的 POST 表单模板中，加一个{% csrf_token %} 标签，它的功能其实是给form增加一个隐藏的input标签，如下
，而这个csrf_token = cookie.csrftoken，在渲染模板时context中有context['csrf_token'] = request.COOKIES['csrftoken']
在通过表单发送POST到服务器时，表单中包含了上面隐藏了crsrmiddlewaretoken这个input项，服务端收到后，django 会验证这个请求的 cookie 里的 csrftoken 字段的值和提交的表单里的 csrfmiddlewaretoken 字段的值是否一样。如果一样，则表明这是一个合法的请求，否则，这个请求可能是来自于别人的 csrf 攻击，返回 403 Forbidden.
在通过 ajax 发送POST请求到服务器时，要求增加一个x-csrftoken header，其值为 cookie 里的 csrftoken 的值，服务湍收到后，django会验证这个请求的cookie里的csrftoken字段与ajax post消息头中的x-csrftoken header是否相同，如果相同，则表明是一个合法的请求
具体实现方法
django为用户实现防止跨站请求伪造的功能，通过中间件 django.middleware.csrf.CsrfViewMiddleware 来完成。而对于django中设置防跨站请求伪造功能有分为全局和局部。
全局：
中间件 django.middleware.csrf.CsrfViewMiddleware
局部：
@csrf_protect，为当前函数强制设置防跨站请求伪造功能，即便settings中没有设置全局中间件。
@csrf_exempt，取消当前函数防跨站请求伪造功能，即便settings中设置了全局中间件。
注：from django.views.decorators.csrf import csrf_exempt,csrf_protect
1、原理
在客户端页面上添加csrftoken, 服务器端进行验证，服务器端验证的工作通过'django.middleware.csrf.CsrfViewMiddleware'这个中间层来完成。在django当中防御csrf攻击的方式有两种：
1.在表单当中附加csrftoken
2.通过request请求中添加X-CSRFToken请求头。
注意:Django默认对所有的POST请求都进行csrftoken验证，若验证失败则403错误侍候。
Django 设置 cookie 中的 csrftoken
http://www.mamicode.com/info-detail-2062660.html
VUE向django发送post返回403：CSRF Failed: CSRF token missing or incorrect解决方案：
https://blog.csdn.net/LoHiauFung/article/details/80792334
http://www.cnblogs.com/wangwei916797941/p/9283776.html
⑹ CSRF攻击简介
CSRF（Cross Site Request Forgery），中文翻译为跨站请求欺骗攻击，是一种利用了浏览器漏洞的一种攻击手段，常被黑客用作刷接口的手段。
Cookie是保存在浏览器本地的一些数据，通常服务器会将和用户有关的数据，如登录token存放在Cookie中。浏览器有一套对Cookie的保护措施，比如Cookie按域（domain）存储，Cookie在别的域下是不可见的。
浏览器中的Cookie按照域（Domain）存储，不同域下的Cookie彼此不可见。但是从别的域下发来的请求却能带上这个域的Cookie。带上Cookie是好事，但不可避免的产生一些坏结果，因为Cookie中往往存储了用户的登录token，这使得来自别的域的请求自动处于登录状态，这意味着别的域的请求能模拟用户做出任何事情，比如批量发帖，批量删帖等。
小明是某某社区的用户
虽然跨域请求能带上Cookie，但请求前却无法看到Cookie中的内容，那么我们只要在Cookie中加上一个字段（X-CSRF-TOKEN）并在别的地方如Header中加上一个一模一样的字段，在服务器收到请求时校验这两个字段是否一致，便能防御CSRF攻击。
生成X-CSRF-TOKEN有两种策略：
1.在登录时由服务器下发给Cookie。
2.前端通过随机数生成，当发送请求时，发现Cookie中没有X-CSRF-TOKEN字段，便给Cookie加上该字段。
实践时我采用了前端随机生成Token的方法，实现过程中也遇到了一些问题。
1.如何生产Token
通过随机数生成的Token实际上就是时间戳。这种随机数是可以被碰撞攻击的。比如用户生成了Token就被CSRF，那CSRF中携带的Token完全可能与我们生成的Token一致。解决方法是通过服务器下发的登录Token+时间戳做一个md5作为X-CSRF-TOKEN。
但这由带来了另一个问题，像登录Token这种重要的数据应该设置为http only，即js不可见，这样才能避免另外一些攻击，因此最好的办法实际是采用服务器下发Token的方式。
2.token放在header中还是放在body里
将Token放在Header中当然是最好的，但在实践中，使用自定义的Header会带来一些跨域的问题。浏览器在遇到跨域并且请求中有自定义Header时，首先它会向服务器发送一个Options请求来获取服务器的跨域策略，即response中的那几个header：
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Credentials
Access-Control-Allow-Headers
因此在服务端我们要在Access-Control-Allow-Methods中加上Options，在Access-Control-Allow-Headers中加上X-CSRF-TOKEN。
然而这还不够，发送Options请求很有可能会失败，如果你有nginx的话。nginx可能会直接将Options请求给拦下来，导致之后的请求无法执行。
⑺ 前后端分离项目——登录Token校验思路
对token的校验分为前端和后端
前端： Vue-Cli 2.x + axios
后端：SpringBoot 2.3.4
这里的话，userToken和userId放到sessionStorage是关键步骤
后端主要是使用拦截器来进行请求的拦截和校验
解释一下思路：
这里的话，针对需要拦截的路径和需要放行的路径进行配置就行
关于redisTemple的引入这里就不再赘述。
到这里为止，前后端的token就都做完了，后面就再讲讲前端的一些其他思路吧
对于登录状态的判断，前端可以在router.foreach上对路由进行状态判定，从而实现页面程度的拦截（具体可以参考最后的参考文章2）
在使用拦截器后，会发现前端部分请求会无法正常到达后端，网络后发现是因为 axios发送正式请求前会先发送一个嗅探请求 ，而嗅探请求是不携带我们封装的header的，所以会导致部分请求会无法成功，解决的方式有很多种，这里的话是选择了在后端去直接处理
参考文章
1、SpringBoot加了拦截器后出现的跨域问题解析
https://blog.csdn.net/mrkorbin/article/details/104066979
2、Vue项目中实现用户登录及token验证
https://www.cnblogs.com/web-record/p/9876916.html
⑻ java怎样传递x auth token在头信息中
简单的就是把token放到session里，如果会话过期，token也就会过期
使用的时候只要判断当前会话是否有效，token是否与客户端传过来的token等就可以了
⑼ vue中怎样添加自定义请求头x-auth-token
axios.create({
baseURL:"https://some-domain.com/api/",
timeout:1000,
headers:{'x-auth-token':'Yourtoken'}
});