跨域servlet理论问题

Posted 2023-03-03

【中文标题】跨域servlet理论问题

【英文标题】：cross origin servlet theoretical question

【发布时间】：2020-01-21 06:10:17

【问题描述】：

我对 CORS 的实现存在理论上的疑问。

启用跨域请求的一种方法是在响应上设置特定的 Header：

private void setAccessControlHeaders(HttpServletResponse resp) 
  resp.setHeader("Access-Control-Allow-Origin", "http://www.allowed.domain.com");
  resp.setHeader("Access-Control-Allow-Methods", "POST");

我的问题是：如果我在response中设置了header（在request-response链的末端），说明我收到的request已经被处理过了，造成副作用 ，然后程序根据响应中是否存在此标头来决定是否必须发回响应。

例如：

public class MyServlet extends HttpServlet 

    //...        

    public void doPost(HttpServletRequest req, HttpServletResponse resp) throws Exception

        Order order = (Order) parseBodyRequest(req);
        orderRepository.save(order);                 //if I check the allowed domains later, I can get serious side effects!

        resp.setHeader("Access-Control-Allow-Origin","http://www.allowed.domain.com");
        resp.getWriter().println("Order n."+ order.getId()+ "has been saved successfully!");
    

在上面的例子中，订单被解析并保存到数据库中，甚至在检查请求来自的域是否被允许之前。

这件事看起来很荒谬，那么它在现实中是如何运作的呢？

【问题讨论】：

***.com/questions/38375124/…

【参考方案1】：

试试这篇文章：https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

简而言之：对于能够更改用户数据的请求，CORS 指定了一个预检请求，该请求询问目标服务器是否会接受具有给定方法和一组标头的请求。 （例如 POST 和 Content-type）而不实际发送请求。浏览器透明地实现了这一点。

【讨论】：

因此，例如，对于 POST 请求，客户端（浏览器、微服务、桌面应用程序）总是发出预请求？还是浏览器的启用/禁用选项？

它是 CORS 的一部分，所以浏览器必须实现它——我猜你也许可以关闭它，但它不是 CORS。