第 1 题:介绍下如何实现 token 加密
<img src="1.jpg" style="width:480px!important;”>
答案:
第一种:
max-width:300px
第二种:
transform: scale(0.625);
第三种
box
box-sizing:border-box;
padding:90px;
来个奇淫技巧
img {
animation: test 0s forwards;
}
@keyframes test {
from {
width: 300px;
}
to {
width: 300px;
}
}
第二题.介绍一下token如何加密
jwt举例
需要一个secret(随机数)
后端利用secret和加密算法(如:HMAC-SHA256)对payload(如账号密码)生成一个字符串(token),返回前端
前端每次request在header中带上token
后端用同样的算法解密
第三题.输出以下代码运行结果
// example 1
var a={}, b='123', c=123;
a[b]='b';
a[c]='c';
console.log(a[b]);
// example 2
var a={}, b=Symbol('123'), c=Symbol('123');
a[b]='b';
a[c]='c';
console.log(a[b]);
// example 3
var a={}, b={key:'123'}, c={key:'456'};
a[b]='b';
a[c]='c';
console.log(a[b]);
这题考察的是对象的键名的转换。
对象的键名只能是字符串和 Symbol 类型。
其他类型的键名会被转换成字符串类型。
对象转字符串默认会调用 toString 方法。
// example 1
var a={}, b='123', c=123;
a[b]='b';
// c 的键名会被转换成字符串'123',这里会把 b 覆盖掉。
a[c]='c';
// 输出 c
console.log(a[b]);
// example 2
var a={}, b=Symbol('123'), c=Symbol('123');
// b 是 Symbol 类型,不需要转换。
a[b]='b';
// c 是 Symbol 类型,不需要转换。任何一个 Symbol 类型的值都是不相等的,所以不会覆盖掉 b。
a[c]='c';
// 输出 b
console.log(a[b]);
// example 3
var a={}, b={key:'123'}, c={key:'456'};
// b 不是字符串也不是 Symbol 类型,需要转换成字符串。
// 对象类型会调用 toString 方法转换成字符串 [object Object]。
a[b]='b';
// c 不是字符串也不是 Symbol 类型,需要转换成字符串。
// 对象类型会调用 toString 方法转换成字符串 [object Object]。这里会把 b 覆盖掉。
a[c]='c';
// 输出 c
console.log(a[b]);
第四题.Vue 的父组件和子组件生命周期钩子执行顺序是什么
加载渲染过程
父beforeCreate->父created->父beforeMount->子beforeCreate->子created->子beforeMount->子mounted->父mounted
子组件更新过程
父beforeUpdate->子beforeUpdate->子updated->父updated
父组件更新过程
父beforeUpdate->父updated
销毁过程
父beforeDestroy->子beforeDestroy->子destroyed->父destroyed
。
第五题.input 搜索如何防抖,如何处理中文输入
当用中文输入法的时候,这时即使我们还在拼写的时候,仍然会触发input事件。
如果你不想还没真正的输入完一个中文就触发input的时候,你可以用这几个原生的api辅助你判断是否真正输入完一个中文:
1.compositionstart,键盘按下的时候触发,此时可能你刚刚按下一个n,但是这个并不是英文输入法的n。
2.compositionupdate,每次输入中文输入法的拼音就会触发,并且这个事件触发会紧接着触发一个input事件。
3.compositionend,输入框的拼音变成中文的时候触发,或者结束中文输入也会触发(在中文输入的时候,按esc或者失去焦点)
因此,你可以在<input>上监听这三个事件,当compositionstart和compositionupdate这两个个事件触发的时候,设置一个boolean值,然后续的input事件不要这么快去做一个逻辑,再compositionend触发时再改变这个boolean值,去操作一些事情了。
<input type="text" id="test">
var test = document.getElementById('test')
test.addEventListener('compositionstart', function (e) {
console.log('compositionstart')
}, false)
test.addEventListener('compositionupdate', function (e) {
console.log('compositionupdate')
}, false)
test.addEventListener('compositionend', function (e) {
console.log('compositionend')
// 去搜索
}, f
。
第六题.周一算法题之「移动零」
示例:
输入: [0,1,0,3,12]
输出: [1,3,12,0,0]
说明:
必须在原数组上操作,不能拷贝额外的数组。
尽量减少操作次数。
function zeroMove(array) {
let len = array.length;
let j = 0;
for(let i=0;i<len-j;i++){
if(array[i]===0){
array.push(0);
array.splice(i,1);
i --;
j ++;
}
}
return array;
}
第七题.(京东)写出如下代码的打印结果
function changeObjProperty(o) {
o.siteUrl = "http://www.baidu.com"
o = new Object()
o.siteUrl = "http://www.google.com"
}
let webSite = new Object();
changeObjProperty(webSite);
console.log(webSite.siteUrl);
对象传值传的是引用,但是引用是copy给函数形参。
// 这里把o改成a
// webSite引用地址的值copy给a了
function changeObjProperty(a) {
// 改变对应地址内的对象属性值
a.siteUrl = "http://www.baidu.com"
// 变量a指向新的地址 以后的变动和旧地址无关
a = new Object()
a.siteUrl = "http://www.google.com"
a.name = 456
}
var webSite = new Object();
webSite.name = '123'
changeObjProperty(webSite);
console.log(webSite); // {name: 123, siteUrl: 'http://www.baidu.com'}
第八题.HTTPS 握手过程中,客户端如何验证证书的合法性
还不了解https握手的请先阅读一次安全可靠的通信——HTTPS原理
大家在网络冲浪时, 在访问一些涉及金融/支付/登录/后台等敏感业务时, 会发现这些网站都会重定向到 https:// 的 URL , 例如:


地址为绿色, 表示安全且可信任;
地址为红色, 则表示虽然开启了加密, 但网站身份未验证, 无法保证不被中间人嗅探.
从我们在地址栏敲下 https:// 网站那一刹那, 到内容显示到我们面前, 中间经过了哪些过程了? 浏览器根据什么来判断, 当前网站网址是安全的还是未验证的? 这篇文章可帮助你了解到这些. 考虑到个人知识所限, 难免有遗漏或错误之处, 如你有发现, 请在下面留言指出.
图示:

讲解:
1. Client-hello 阶段
浏览器中完成地址输入后, 解析域名获得 IP Host 地址, 浏览器会与此 Host 的443(默认, 如果指定其他端口则会连接此端口) 尝试连接, 也就是 TLS 握手协议的 Client-hello, 上图的第一步.
浏览器会将"支持的加密组件"/"尝试连接到Host头"等信息发送给服务器, 并会附上一份随机生成的 session ticket1.
2. Server-hello 阶段
服务器收到浏览器发送来的 TLS 握手请求后, 存储浏览器发送的session ticket2, 然后根据发送来的 host 寻找对于的服务器证书, 然后会将服务器证书, 服务器与浏览器妥协(均支持)的加密套件方法, 和一份随机生成的 session ticket 返回给浏览器.
3. Cipher-spec 阶段
浏览器收到服务器返回的证书后, 会验证证书有效性. 验证步骤大概如下:
验证证书有效期(起止时间)
验证证书域名(与浏览器地址栏中域名是否匹配)
验证证书吊销状态(CRL+OCSP), [见本文后"吊销检查"章节].
验证证书颁发机构, 如果颁发机构是中间证书, 在验证中间证书的有效期/颁发机构/吊销状态. 一直验证到最后一层证书, 如果最后一层证书是在操作系统或浏览器内置, 那么就是可信的, 否则就是自签名. [见本文后"签发者"章节]
以上验证步骤, 需要全部通过. 否则就会显示警告.
若检查通过, 随机生成一份 session ticket 3 (这是浏览器生成的第二份 ticket), 通过返回证书中的公钥, 用协商的"秘钥交换算法"加密, 返回给服务器.
同时浏览器用 session ticket 1(浏) & session ticket 2(服) & session ticket 3(浏) 组合成 session key.
服务器收到 Ciper-spec 后, 用配置的私钥, 解密出 session ticket3, 用 session ticket 1(浏) & session ticket 2(服) & session ticket 3(浏) 组合成 session key.
此处不难得知, 服务器与浏览器交换的最终秘钥, session key全等且未泄露(session ticket 1 和 session ticket 2可以抓包, 但session ticket 3是无法窃听的).
为什么session ticket 3无法窃听?
有个 webtrust 组织, 专门负责备案世界上各国商业与政府官方 CA 机构的公钥证书. 如果审计通过, 其他浏览器及操作系统/客户端才允许加入信任列表. 否则是不允许加入的. 如果中间人拦截了 session ticket 3 的响应密文, 没有私钥, 中间攻击人是解密不了的. 而要想拿到私钥, 攻击人可以做到, 就是在客户端和服务器中间搭建代理, 替换掉 SSL 证书, 以实现服务器返回证书时候中间替换自己的, 从而在中间拦截服务器和客户端两头的通信.
但是如果这样做, 浏览器和客户端会显示非信任的颁发者, 如下图 chrome 和 curl 命令行下分别警告:


4. 内容传输阶段
至此, TLS 连接建立完成, 在连接销毁前, 浏览器与服务器彼此数据均通过 session key 来进行对称加密.
通过
上述过程, 其实是别有用心的, 因为非对称加密非常消耗 CPU. 所以只有在协商秘钥时候使用非对称加密, 而应用层数据交换就用协商成功的秘钥作为私钥对称加密传输(服务器响应的加密返回, 客户端提交的也加密提交).
吊销检查:
目前写进国际标准的吊销状态检查协议有两种: 1.CRL, 2. OCSP

CRL 是一份全量的文件, 记录了被此 CRL 限制的证书中所有被吊销证书的序列号. 通过匹配当前证书序列号, 与 CRL 中序列号, 来判断.
有点绕, 反正就说, 所有打上了这个 URL 的 CRL 的证书, 只要其中一个被吊销, 那么下次 CRL 更新时, 均会查询匹配到.
那么可不可以认为一个中间颁发机构颁发的证书的 CRL 列表只有一个? 不可以! 因为数量可能太多, 厂商完全可以将同一个中间证书颁发的最终证书, 分不同批打不同的 CRL.
而 OCSP 是 TCP 服务, 通过请求证书序列号, 服务器告知当前序列号是否在被吊销名单.
有的证书内置了 CRL+OCSP, 有点只内置了 OCSP, 还有的早起证书只内置了 CRL, 但只内置 CRL 的证书是不被新型浏览器信任了.
请思考:
问: 吊销状态检查, 是同步的还是异步的?
答案: 同步的.
如果异步检查, 有可能会导致浏览器发送数据给了未验证的主机后, 过了一段时间才检查出来证书已吊销. 所以, 必须同步
签发者:
证书的签发者, 通过以下步骤获得
1. 服务器证书, 如果包含了证书链, 浏览器会尝试匹配(根据当前证书的"签发者公钥"匹配链中的后续证书的"公钥"), 如果匹配失败, 走2.
2. 中如果有声明 签发者 URL, 浏览器尝试下载. 并通过公钥匹配(同1), 如果匹配失败, 走3

3. 操作系统或客户端浏览器内置证书公钥匹配, 如果匹配失败, 则返回ERR_CERT_AUTORITY_INVALID.
4. 附加项: 如果任何一级证书, 被声明了 oID, 则会被浏览器显示成 EV(绿色地址栏带上公司名称).

题外话:
问: HTTPS 是否会拖慢性能?
答案: 看具体部署的情况.
浏览器在加密 session ticket3时, 和服务器在接受浏览器返回 session ticket3时, 是非对称加密中可能出现耗时的步骤. 但这个步骤顶多几毫秒, 并且现代化浏览器和 NGINX 已经支持 session 复用, 造成的性能损耗几乎可以忽略不计.
而真正可能拖慢性能的, 只可能是在吊销检查步骤中.
因为上面说了, 吊销状态检查只能是同步的, 那么受到 CA 厂商的部署限制, 极可能会将 CRL 服务器和 OCSP 服务器部署在遥远的小机房, 带宽/链路都是极差的, 这种, DNS 解析和连接 CRL/OCSP 服务器均需要耗时, 此过程的损耗, 是一大批在知乎的所谓专家所言的加密解密过程损耗的数十倍到数百倍.
问: 怎么规避吊销状态带来的损耗?
答案: 仁者见仁, 智者见智. 这里给出两个建议
1. 踩上大厂的顺风车. 如百度阿里腾讯和苹果微软操作系统各种常见网站和软体的服务器/代码签名证书, 均有 CRL 和 OCSP, 而 CRL 是操作系统层复用的, 只要在 TTL 时间内, 操作系统检查过对应 CA 的 CRL, 那么 CRL 均可避免二次下载, 用户访问就可实现加速. OCSP 也至少可以搭上一个免去 DNS 解析的红利. 例如 Symantec/GeoTrust/GlobalSign
2. 买国内 CA 的证书. 我指的是真正自己在浏览器根证书的 CA 啊,不包括仅仅是中间证书分销商, 也不包括前面被除名然后变成分销商的WoSign.
问: 12306的证书部署, 除了 CA 不受信任外, 还有那些错误?
答: 除了 CA 不受信任, 还存在问题:
没有吊销状态声明, 根据最新的 webtrust 标准, 没有声明吊销状态的证书不受信任.
签名算法用了过期的 SHA-1.