Fetch API 入门:替代繁琐的 AJAX

浏览器跨域的原理和实际浏览器中的表现,常见问题和配置指南。

Chrome 80 跨域 Cookie 变化的影响和应对方案

Chrome Cookie SameSite Secure 跨域

根据 时间线 Chrome 80 稳定版本将在 2020-02-04 发布。 它的 变更列表 中有两项 Cookie 安全 相关的变更, 对非安全连接下的 Cookie 设置和 Cookie 跨于发送做了更多限制。 这意味着通过 Cookie 跨域跟踪用户的相关功能可能会受到影响(比如日志、统计), 且只能在 HTTPS 上修复(意味着可以避免针对非安全连接的 MitM 攻击)。 具体地,有这两个 feature: Reject insecure SameSite=None cookies Cookies default to SameSite=Lax 对应的标准草案可以在 IETF 网站找到:Incrementally Better Cookies。 下文关注这两个变更对业务带来的影响,以及可能的应对方案。

Fetch API 入门:替代繁琐的 AJAX

CORS Cookie 跨域 Service-Worker

随着 PWA 进入人们的视野,Fetch 作为除了 AJAX 之外的第二个 JavaScript HTTP API 开始引起人们的关注。 Service Worker 中通常利用该 API 进行真正的网络请求并应用相应的缓存策略。 本文简要介绍 Fetch API 的使用,Service Worker 与 Window 中的实现差异,以及跨域 Fetch 的问题。 目前 Web 异步应用都是基于 XMLHttpRequest/ActiveXObject 实现的, 这些对象不是专门为资源获取而设计的,因而它们的 API 非常复杂,同时还需要开发者处理兼容性问题。 虽然开发者普遍使用 $.ajax() 这样的上层包装,但 Fetch API 意在提供更加方便和一致的原生 API, 同时统一 Web 平台上的资源获取行为,包括外链脚本、样式、图片、AJAX 等等。

重定向 CORS 跨域请求

Chrome HTTP Safari iOS CORS 跨域 XHR

TL; DR 非 简单请求 不可重定向,包括第一个 preflight 请求和第二个真正的请求都不行。 简单请求可以重定向任意多次,但如需兼容多数浏览器,只可进行一次重定向。 中间服务器应当同样配置相关 CORS 响应头。

CORS 跨域中的 preflight 请求

跨域 CORS AJAX HTTP XHR

我们知道借助 Access-Control-Allow-Origin 响应头字段可以允许跨域 AJAX, 对于非 简单请求,CORS 机制跨域会首先进行 preflight(一个 OPTIONS 请求), 该请求成功后才会发送真正的请求。 这一设计旨在确保服务器对 CORS 标准知情,以保护不支持 CORS 的旧服务器。 Wikipedia: https://upload.wikimedia.org/wikipedia/commons/c/ca/Flowchart_showing_Simple_and_Preflight_XHR.svg

CORS 跨域发送 Cookie

AJAX Cookie XHR CORS 跨域

在 Web 页面中可以随意地载入跨域的图片、视频、样式等资源, 但 AJAX 请求通常会被浏览器应用同源安全策略,禁止获取跨域数据,以及限制发送跨域请求。 虽然 有多种方法利用资源标签进行跨域,但能够进行的数据交互非常有限。 在 2014 年 W3C 发布了 CORS Recommendation 来允许更方便的跨域资源共享。 默认情况下浏览器对跨域请求不会携带 Cookie,但鉴于 Cookie 在身份验证等方面的重要性, CORS 推荐使用额外的响应头字段来允许跨域发送 Cookie。

Web 开发中跨域的几种解决方案

DOM HTML HTTP JavaScript jQuery iframe JSON 跨域 CORS

这些办法大致可以分为两类: 一类是 Hack,比如通过 `title`, `navigation` 等对象传递信息,JSONP 可以说是一个最优秀的 Hack。 另一类是 HTML5 支持,一个是 `Access-Control-Allow-Origin` 响应头,一个是 `window.postMessage`。 跨域的正道还是 HTML5 提供的 CORS 头字段以及 `window.postMessage`, 可以支持 POST, PUT 等 HTTP 方法,从机制上解决跨域问题。