很多朋友对于俱乐部网站源码分享和俱乐部代码不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！
我相信每一个前端在对接API时，多多少少一定遇过以下错误：
虽然要解决此问题大部分还是需要后端帮忙，但前端也需要知道为什么会发生、要如何解决。
同源政策(SameOriginPolicy)
同源政策是网站安全的基础。https://domain-a.com只能存取自己网站裡的资源(图片、影片、源码代等)，不允许网站https://domain-b.com来存取。想要存取跨来源资源必须在某些特定情况下才被允许。
画清楚界线自己网站自己管，别人读取不到也改不了。这很合理，不然若自己网站被别人任意修改、被恶意人士读取机密资讯那就糟糕了！若没有这层防护，坏人就可以任意新增删除我们在各大社区里面留言了、也可以轻易登入我们的银行帐户。
怎麽判断同不同源?
只要scheme、domain、port一样就会被视为同源(same-origin)，其他则是不同源
若以https://domain-a.com:80/hannah-lin做范例，我们可以因此判断跟以下是否同源:
http://domain-a.com→不同源．scheme不同\nhttps://domain-a.com/mike→同源\nhttps://news.domain-a.com→不同源．domain不同\nhttps://domain-a.com:81→不同源．port不同\nhttps://domain-b.com→不同源．domain不同\n
Note.IE对于不同port会视为同源
但我网站明明就引入很多跨来源的资源啊？
网页常见的跨来源资源真的不少，例如以下:
没错，在某些情况下跨来源是被允许的，不受同源策略限制
跨来源嵌入通常被允许(embed)
像范例的<scriptsrc=”…”></script>、<linkrel=”stylesheet”href=”…”>、<iframe>、图片<img>、<video>、或是@font-face<object>、<embed>.等等都是跨来源嵌入。
跨来源写入通常被允许(writes)
可以在藉由<form>在domain-a.com发request给domain-b.com，当然透过连结links或直接redirect到别的网站也是被允许的。
跨来源读取通常被禁止(reads)
domain-a.com不能读取domain-b.com的cookie、XMLHttpRequest，FetchAPI也都无法被读取，会回报错误:
同源政策(SameOriginPolicy)允许HTMLtag产生的跨来源写入(write)/嵌入(embed)/读取(read)，但对于JS的跨来源write/embed/read是有限制的。
那什麽是Cookie的同源?
Set-Cookie:<cookie-name>=<cookie-value>\nSet-Cookie:id=1234567;domain=hello.com\n
前端都知道Cookie是什麽，简单来说就像一张通行证，通行证裡面会存有一组SessionID来验证你身份，就像你加入某某俱乐部一样，认卡不认人，谁拥有这张通行证就可以进入俱乐部。
Cookie的同源跟以上所说的DOM同源有点不同(图片或是源代码等资源被载入浏览器最后都会变成DOM的元素)
只要domain跟Path与Cookie上的一样就会被视为同源。若经过一些设定才会判断scheme要是http或https。
//加了Secure会限定此Cookie只能以https传送\nSet-Cookie:id=1234567;domain=hello.com;Secure\n
另外要注意的是子网域的cookie是可以存取到母网域cookie的(api.domain-a.com跟domain-a.comcookie可以被共用)
对了，同源政策是浏览器专属，所以才会发生用postman可以拿到API回应但放到网站上就是会失败的状况。
CORS(Cross-OriginResourceSharing)
CORS翻成中文就是跨网域资源共享，也就是你可以用我资源我也可以用你的
为什麽会有CORS
**SameOriginPolicy**虽然不错，因为他防止了一些恶意的script攻击，但总不会每一个跨网域都是恶意的;也不可能一间公司拥有所有的资源，有时还是必须串接第三方资源，例如FacebookAPI、GoogleMap、政府提供的公开API等。
怎么设置
设置CORS相当容易，它其实只是HTTP-Header而已，这些设定基本上都是在后端，所以前端只需知道概念跟怎麽看ResponceHeader即可。
当前端用fetch或XMLHttpRequest要存取资源时，在request之前都会先发送preflightrequest确定server端有设定正确的相关Http-Header，若检查通过，才会实际发出requeest。例如
fetch(&39;,{\nmethod:&39;,\nheaders:{\n&39;:&39;,\n}\n})\n
那requestheader会大概长这样
POST/data/\nHost:xxx.com\nOrigin:https://myweb.com\nContent-Type:application/json\n
preflightreques会大概是这样:
OPTIONS/data/\nHost:xxx.com\nOrigin:https://myweb.com/\nAccess-Control-Request-Method:POST\nAccess-Control-Request-Headers:Content-Type\n
可以在developertools中的Network看到相关的ResponceHeader
当然后端可以把权限开到最大让任何人都可以读取，不受同源政策的限制
Access-Control-Allow-Origin:*\n
但跨来源还是有许多风险的，所以建议还是不要直接*。
//还是会针对特定网站开权限\nAccess-Control-Allow-Origin:https://foo.example\n\n//可以设定允许哪些method，defult是全部方法\nAccess-Control-Request-Method:POST,GET\n\n//允许clientside带cookie等验证，defult是false\nAccess-Control-Allow-Credentials:true\n
preflightrequest?
不是simplerequest都会先发一个preflightrequest确定server端有设定正确的相关Http-Header，也就是会先问server是否允许这个request，允许的话才会正式request。像HTTPPUT/DELETEmethod，或Content-Type:application/json都会先发preflightrequest。
有同源政策的保护，我的网站就是安全的吗?
答案：不能。
SameOriginPolicy只是最基本的保护而已，实际上attackers还是可以聪明地找到漏洞攻击你的网站。例如Cross-sitescripting(XSS)可以欺骗网站来绕过同源政策的保护，这是一个很大的问题，因为同源政策下浏览器信任底下所有资料存取都是安全的，但这样被恶意注入利用很有可能就让你网站挂掉，更严重是用户敏感资料被洩漏，应该被保密的资料被坏人利用。
HTML5SecurityCheatsheet这个网站蛮酷的，提供各种XSS变形手法程式以及范例可以上去玩玩看
要确保自己网站的安全，还是需要下功夫的，接下来也会介绍一些简单的方法来保护你的网站！
作者：HannahLin来源：medium原文：https://medium.com/starbugs/%E5%BC%84%E6%87%82%E5%90%8C%E6%BA%90%E6%94%BF%E7%AD%96-same-origin-policy-%E8%88%87%E8%B7%A8%E7%B6%B2%E5%9F%9F-cors-e2e5c1a53a19
俱乐部网站源码分享的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于俱乐部代码、俱乐部网站源码分享的信息别忘了在本站进行查找哦。