DAY04 - API串接常见问题 - CORS - 概念篇 (1)

记得我第一次正式的串接API的时候，踏着愉悦的心想说自己要成为一个真正的前端要来串接了～～～ 结果写了对应的程序打API之後，资料没有出来，还马上在console里收到一个红红的错

这个问题通常因为放到正式环境又没问题了，或者直接拍出大绝请後端开好开满，把 Access-Control-Allow-Origin: *设定完成，几乎就解决问题了～
没错，如果你只想30秒解决这个问题，告诉你一个快速的结论：
请後端工程师，在API的header加上这个设定属性Access-Control-Allow-Origin: *

但只要这样就够了吗？身为一个追根究底的工程师，我们应该知道为什麽会有这个问题吧！或是如果在本机开发遇到这个状况该怎麽处理？或是知道之後才方便之後被面试问到的时候不会答不出来吧(?)

好啦，有这麽多理由该知道，那我们就开始吧！

从错误讯息出发

其实错误讯息里就告诉你为什麽了

access to XMLHttpRequest at 连结A from origin 连结B has been blocked by CORS policy: response to preflight request doesn't pass access control check: No 'Access-control-allow-origin' header is present on the requested resource

当你要从连结B要request到连结A时，被CORS的政策挡下来了，冒号後面告诉你原因：因为preflight request没有通过存取检测，请检查看看request的来源的header有没有access-control-allow-origin。

实务上就是我的前台网站在 连结A 但需要透过API 连结B 时，前後台两者网址不同来源，但前台要取得不同来源的资料时，若没有做好相关的设定就会出现上面的错误

错误讯息好像每个字都看得懂，但CORS是什麽意思？又为什麽要有CORS? header要加的这个又是什麽呢？接下来让我们继续看下去～

Same Origin Policy (同源政策)

在开始CORS之前，我们需要先知道浏览器的Same Origin Policy(同源政策)。
浏览器基於安全性的考量，规定当你的网站要呼叫API时，需要是同一个来源。
如果是不同来源，浏览器依然会帮你发出request，但会把收到的response阻挡起来不给你的网站。

那什麽叫同一个来源呢？

同源(Same-Origin)？ 跨来源(Cross-Origin)？ 来源怎麽判定？

当两个网址的 schema(protocol) + host + port 皆相同，就是同源(Same-Origin)，只要有一者不同，就是跨来源(Cross-origin)

以下举几个范例：

了解了同源、跨来源後，你应该接下来马上会想到... 怎麽可能我要打的API都是同一个来源呢？如果就是不同源该则麽办？

所以我们需要CORS! 什麽是CORS?

CORS = 跨来源资源共用（Cross-Origin Resource Sharing (CORS)）。

跨来源资源共用 : 发出request的来源不同，但需要共用资源

可以把API request想像成大楼里的一个个部门办公室，有各自的门禁卡。资讯部的人不能进到行销部，因为他们是不同来源。那如果最近资讯部跟行销部密切合作，希望可以让资讯部的人直接进到行销部怎麽办？这时候浏览器就是这个开启门禁卡权限的管理员，要开启门禁权限的方法就是CORS

• 这边我们要注意一点，门禁权限是浏览器订的，意思是如果今天管理员换人了，不是浏览器了，那部门之间的门禁就消失了，就不会有不同来源会被阻挡下来的问题（所以你有发现吗
  我们用postman打API的时候，就不会看到CORS的问题，因为管理员是postman不是浏览器了!)

CORS的运作原理

简单来说，要开启不同来共享资源的方式就是：透过在API的response中加入新的http header让浏览器透过这些资讯，来决定要不要放行这个response。

我们已经简单的知道为什麽我们会遇到这个问题了，那要怎麽加上新的http header当作跨来源的通行证? 又详细的运作原理是什麽呢？待明天揭晓～

参考资料

• CORS 完全手册：为什麽会发生 CORS 错误？ https://blog.huli.tw/2021/02/19/cors-guide-1/
• MDN - CORS
  https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS