XSS 攻击本身危害可能并不是很大 但是往往是其它类型攻击的入口 如果是存储型 可以影响很多其它用户 就算是纯粹的反射型也可以诱导用户点击 然后注入脚本 盗取 cookie 或者 直接控制用户 代替用户做任何事情

举个例子 如果你是管理员 有人给你发钓鱼邮件 里面有伪装过的 XSS 注入脚本的链接 你点击后 由于你已经管理员账号登陆 可以盗取你的 cookie 就算是 cookie 不可读 也可以用你管理员的身份 创建新管理员账号 或者直接就是破坏 反正你能做的事 注入的脚本也可以

在比如 如果是聊天系统或者可以发送内容的系统 一个人中 XSS 注入脚本就可以利用这个人登陆的账号公开或者对其他账号发送注入的链接达到传播的目的

防范也很简单 基本上就是 根据是 html 内容还是属性进行编码就可以解决

lz 不知道苹果有 lightening 到 usb typec 的线吗 而且还支持 usb 3.0 （当然 需要 iPad Pro 才支持这个速度）

@odirus 显示出来的字符串 iOS 当然必须是对的 会有专人翻译和校对
但是代码里面的变量 常量 类和方法名 当然是按照代码规范来写
但是我们不是核心团队所以没有统一的代码规范
我写 JS PHP 的时候

常量全大写 IOS_VERSION 总不会写成 iOS_VERSON 吧

其它情况就很多了 有 IOSClass IosClass IPhoneClass IphoneClass 甚至 iOSClass iPhoneClass 的
getIOSVersion getIosVersion 甚至 getiOSVersion 的

这些用户是看不见的 而且我也不写开放的 API 所以产品和管理不会管的

@odirus 很合理的编码规范啊 严格遵守驼峰 就算是专有名词 我记得貌似 Google 的规范就是这样
你想想那么多专有名词 如果保持原样写在一起根本分不出来
QQ IP 之类的还好 iOS iPhone macOS 就更糟糕了

以前在 Apple 的时候 我们小组没有统一编码规范 有人坚持要保证这些专有名词的大小写正确
而我和几个新来的又坚持严格遵守驼峰 于是 iOS IOS Ios 混杂 代码没法看了

看看下面的这些方法 你觉得是那个好呢？

is iOS IPSec Tunnel Ready for SaaS API:
isiOSIPSecTunnelReadyforSaaSAPI
isIosIpsecTunnelReadyForSaasApi

get QQ FQDN IP in JSON:
getQQFQDNIPinJSON
getQqFqdnIpInJson

@Sanko 要看你 cron 是 root 的还是你自己用户的

如果是你自己用户的话 估计是环境变量的问题 因为 cron job 的 shell 可能和你的 terminal 不同 所以 profile 之类的可能没有运行 path 之类的可能不对

如果是 root 的话 估计就是 ssh key 的问题 因为用户不同 root 找不到你 用户的 key

应该是没有 ssh key 的原因

MBP 盒子说明书那包里面送了一块超级好的眼镜布 黑色仿皮的 大部分人都没注意扔了
我也是在收集里面苹果贴纸的时候意外发现的 都放里面一年多了

@lovestudykid 黑猩猩会使用工具 还会制作简单的工具 甚至还会学别的猩猩制作工具 还可以协作制作和使用工具

估计并不是你想的那样的
其实仅仅是 Apple 把沃通的根证书拉黑了而已 不仅仅是不再信任

证书系统里面既有白名单也有黑名单
不信任证书 是上游证书没有在白名单里面
但是只要不在黑名单中 各大浏览器都只是给你警告 你还是可以继续访问 （自签证书或证书被取消 算这类）
但是如果在黑名单里面了 有已知风险 那么浏览器是不会让你继续访问的（这就是沃通证书目前的情况）
目前由于沃通一而再的违反准则和规避制裁 导致各大国际浏览器厂商都拉黑了他的 CA 证书 甚至是中间证书

确实 一般公司防火墙都对端口设了白名单 只有一些比较标准的端口可以访问
一般的解决方案就是把端口改成 80/443/8080/8443 之类不会被封的端口
但是有些火墙比较强大 会要求端口和实际通过端口的协议必须一致（也就是说 80 端口必须是 HTTP 协议） 所以就没办法把 SS 改到这些端口

看这邮箱 怎么感觉是钓鱼来着 会不会是哪里泄漏了

虽然我没有这车 但是坐过同事的
表示一般情况下不会有这样的问题 因为打开的过程中 门并不会展的很开
普通车门要打开也需要不少的空间 大概半米到一米的样子对吧
不然的话 就算普通车门打开 距离太近也会蹭到别人的车
这个特斯拉 X 的车门需要的空间我记得是差不多的
如果你说很挤的时候 那么如果普通车门打开都有问题的话 这个翼型车门估计也够呛
我记得没错的话 如果空间不够 车门会感应 停止展开 但是我不太确定

开发者不会喜欢这个机制的 因为这个不是可控的
因为这么做就没办法实现 视差滚动 (Parallax Scrolling) 了
而且也有很多需要 scroll event 调整页面的效果也没办法实现了
也没法模拟实现 position sticky 或 fixed
相比之下 Google 推的 passive event listener 的机制就好很多

@Septembers EventSource 就是 SSE 的 API interface

@lyhiving 这个已经是标准的一部分了 好像是和 WS 同时间标准化的 所以不能说是又一个轮子
和 WS 其实完全不是一个东西 SSE 基本上就是改进版的长轮询 其实 HTTP2 才是一个大轮子

WS 是用来做“实时双向通讯”的 但是大部分人只用 WS 做服务器端 Push 其实是大材小用了 因为 WS 是一个全新的协议
而 SSE 基于 HTTP 1.1 实现了服务器端 Push 比 WS 简单很多 而且有 Polyfill 可以支持几乎所有主流浏览器

对于后端语言 SSE 也比 WS 容易实现很多 比如老版本的 PHP 就没办法直接实现 WS 但是可以实现 SSE
如果没有形成 WS 库的后端语言 要实现一个 WS 协议很难 但是实现一个 SSE 基本上没什么问题

不过不管是 WS 还是 SSE 对于 HTTP2 而言 都是要被淘汰的东西 因为 HTTP2 实现了 WS 和 SSE 需要的功能 而且开销要小很多 目前只是没有很好的 API 来操作罢了
可能以后会出来 WS 和 SSE 的 HTTP2 版本 API 基本不变 但是底层换成 HTTP2 实现

这个和内网或者 localhost 没关系

是 Chrome 不再匹配证书的 CN

而只匹配证书的 SAN 扩展了

你到 DevTools 的 Security 里面可以看到警告说明原因

Ajax 错误本来就是 window.onerror 捕捉不到的呀 Ajax 错误应该是 xhr 的 onerror
Chrome console 里面显示的 大都 onerror 捉不到的 比如 console log 就不是 onerror

既 polyfill 了，为什么还要转换。polyfill 意思就是某个功能不支持，就把它补上。
所以 里面应该已经实现了 Array.of 了。
当然，如果运行的时候抱错了，那就说明没用上。