本文深入探讨了PHP与JavaScript进行跨域资源共享（CORS）时遇到的常见问题，特别是“Cross-Origin Request Blocked”错误。教程详细解释了CORS机制，包括预检请求（OPTIONS）的处理，并提供了在PHP后端正确配置`Access-Control`系列HTTP响应头的实用代码示例和最佳实践，旨在帮助开发者有效解决跨域通信障碍。
深入理解跨域资源共享（CORS）
在现代Web开发中，前端（如使用JavaScript）与后端（如使用PHP）进行数据交互是常态。然而，由于浏览器的“同源策略”（Same-Origin Policy）安全限制，当一个网页尝试请求不同源（协议、域名或端口任一不同）的资源时，浏览器会阻止该请求，并抛出“Cross-Origin Request Blocked”错误。这就是跨域问题。
为了解决这一问题，W3C推出了跨域资源共享（CORS）标准。CORS允许服务器在响应头中声明哪些源可以访问其资源，从而放宽同源策略的限制。
CORS请求类型与预检请求（Preflight Request）
CORS请求分为“简单请求”和“非简单请求”。
立即学习“PHP免费学习笔记（深入）”；
简单请求：满足以下所有条件的请求：
- 使用GET、HEAD或POST方法。
- 请求头中只包含CORS安全列表中的字段（如Accept, Accept-Language, Content-Language, Content-Type）。
- Content-Type的值仅限于application/x-www-form-urlencoded、multipart/form-data或text/plain。
非简单请求：不满足简单请求条件的任何请求，例如：
- 使用PUT、DELETE等HTTP方法。
- 发送Content-Type为application/json等非简单类型。
- 包含自定义请求头。
对于非简单请求，浏览器在发送实际请求之前，会先发送一个OPTIONS类型的“预检请求”（Preflight Request）到目标服务器。这个预检请求的目的是询问服务器，是否允许当前源发送实际请求，以及允许使用哪些HTTP方法和请求头。服务器必须对这个预检请求做出正确的响应，包含一系列Access-Control头部，浏览器才会继续发送实际请求。如果预检请求失败（例如，服务器没有正确响应CORS头），浏览器将直接阻止后续的实际请求。
PHP后端CORS配置核心：Access-Control响应头
解决跨域问题的关键在于服务器端（PHP）正确设置CORS相关的HTTP响应头。以下是几个最重要的头及其作用：
-
Access-Control-Allow-Origin:
- 作用: 指定允许访问资源的源。
-
值:
- * (星号): 允许任何源访问。在开发环境中方便，但在生产环境中不推荐，因为它存在安全风险。
- 具体的域名: 例如 http://localhost:4200 或 https://your-frontend-domain.com。这是最安全的做法，只允许特定的前端域名访问。
- 注意事项: 如果设置了Access-Control-Allow-Credentials: true，则Access-Control-Allow-Origin不能设置为*，必须是具体的域名。
-
Access-Control-Allow-Methods:
- 作用: 指定允许的HTTP请求方法（如GET, POST, PUT, DELETE, OPTIONS）。
- 值: 逗号分隔的HTTP方法列表，例如 GET, POST, OPTIONS, PUT, DELETE。
-
Access-Control-Allow-Headers:
- 作用: 指定允许的自定义请求头。
- 值: 逗号分隔的请求头名称列表，例如 Content-Type, Authorization, X-Requested-With。
-
Access-Control-Allow-Credentials:
- 作用: 指示是否允许发送Cookie、HTTP认证信息等凭证。
- 值: true 或 false。如果设置为true，客户端JS的fetch或XMLHttpRequest需要设置credentials: 'include'。
-
Access-Control-Max-Age:
- 作用: 缓存预检请求的结果，避免每次都发送OPTIONS请求。
- 值: 一个整数，表示预检结果可以缓存的秒数。例如 86400（一天）。
PHP后端CORS配置示例
以下是一个健壮的PHP代码示例，用于处理CORS请求，特别是预检请求：
true,
'message' => 'Data received successfully!',
'data' => $_POST // 假设是POST请求，这里可以处理请求体
);
echo json_encode($response);
}
}
?>代码解析：
-
动态设置 Access-Control-Allow-Origin:
- 首先尝试从$_SERVER['HTTP_ORIGIN']获取客户端的源。
- 定义一个$allowedOrigins数组，列出所有允许访问的域名。
- 通过in_array检查请求源是否在允许列表中，以确保安全性。
- 重要: 避免在生产环境中使用Access-Control-Allow-Origin: *，除非你明确知道其含义和风险。
-
设置 Access-Control-Allow-Credentials 和 Access-Control-Max-Age:
- Access-Control-Allow-Credentials: true 允许客户端发送和接收Cookie等凭证。
- Access-Control-Max-Age: 86400 缓存预检请求结果一天，减少不必要的网络往返。
-
处理 OPTIONS 预检请求:
- 通过$_SERVER['REQUEST_METHOD'] == 'OPTIONS'判断当前请求是否为预检请求。
- 如果是，则设置Access-Control-Allow-Methods和Access-Control-Allow-Headers。$_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']会包含浏览器在实际请求中打算发送的自定义头，直接回显可以确保兼容性。
- 关键: 在设置完所有CORS头后，必须使用die('OK')或exit()终止脚本执行。预检请求只关心服务器是否允许，不关心实际的业务逻辑响应。如果此处不终止，服务器可能会返回非预期的内容，导致浏览器认为预检失败。
-
处理实际请求:
- 如果请求不是OPTIONS（即实际的GET、POST等请求），则继续执行您的业务逻辑。
- 设置Content-Type: application/json，并返回您的JSON响应。
JavaScript客户端代码示例
前端JavaScript代码通常不需要为CORS做特殊处理，只需按照正常的fetch或XMLHttpRequest方式发送请求即可。如果后端设置了Access-Control-Allow-Credentials: true，前端也需要相应地设置：
const url = 'https://opecart9349.000webhostapp.com/unzipper/opencart/index.php?route=customapi/test';
fetch(url, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
// 如果后端允许，可以添加自定义头，例如 'Authorization': 'Bearer YOUR_TOKEN'
},
// 如果后端设置了 Access-Control-Allow-Credentials: true，则需要添加此项
credentials: 'include', // 允许发送和接收Cookie等凭证
body: JSON.stringify({ key: 'value' }), // 示例：发送JSON数据
})
.then(response => {
// 检查响应状态码，处理HTTP错误
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
return response.json();
})
.then(data => {
console.log(data);
})
.catch(error => {
console.error('Error:', error);
});注意事项与最佳实践
- 安全性: 永远不要在生产环境中使用Access-Control-Allow-Origin: *，除非你明确理解其安全风险。最好是明确列出所有允许的源。
- 调试: 当遇到CORS问题时，首先检查浏览器的开发者工具（Network标签页）。查看OPTIONS请求和实际请求的响应头，确认Access-Control系列头是否正确设置。
- 服务器配置: 确保您的Web服务器（如Apache或Nginx）没有干扰PHP设置的CORS头。有时服务器配置可能会覆盖或阻止PHP设置的头。
- 错误处理: 在PHP代码中，如果请求源不在允许列表中，应该返回一个错误状态码或直接不设置Access-Control-Allow-Origin，让浏览器自行阻止请求，而不是返回不明确的响应。
- HTTP_ORIGIN vs HTTP_REFERER: HTTP_ORIGIN是CORS标准中用于标识请求源的头，通常更可靠。HTTP_REFERER是浏览器发送的，表示请求来源页面的URL，可能会被用户或浏览器配置禁用。
总结
解决PHP与JavaScript之间的CORS问题，核心在于理解同源策略、CORS机制，特别是预检请求（OPTIONS）的工作原理。通过在PHP后端正确配置Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等响应头，并对OPTIONS请求进行特殊处理并立即终止，可以有效地消除“Cross-Origin Request Blocked”错误，实现前后端的安全、顺畅通信。遵循本文提供的代码示例和最佳实践，将有助于构建更健壮、更安全的跨域Web应用。
