පෙනෙන විදිහට, මම එහි අර්ථ නිරූපණය සම්පූර්ණයෙන්ම වරදවා වටහාගෙන ඇත. මම මේ වගේ දෙයක් ගැන හිතුවා:

1. සේවාදායකයෙක් javascript කේතය MyCode.js බාගත කරයි http://siteA- මූලාරම්භය .
2. MyCode.js හි ප්‍රතිචාර ශීර්ෂය තුළ Access-Control-Allow-Origin: අඩංගුhttp://siteB වන අතර, එයින් අදහස් කළේ B වෙබ් අඩවියට හරස් සම්භවයක් දැක්වීමට MyCode.js ට අවසර දී ඇති බවයි.
3. සේවාදායකයා MyCode.js හි යම් ක්‍රියාකාරිත්වයක් අවුලුවන අතර, එමඟින් http://siteBහරස් ප්‍රභව ඉල්ලීම් තිබියදීත්, ඉල්ලීම් කරන අතර එය හොඳ විය යුතුය.

හොඳයි, මම වැරදියි. එය කිසිසේත් මේ ආකාරයට ක්‍රියා නොකරයි. එබැවින්, මම හරස් සම්භවයක් ඇති සම්පත් බෙදාගැනීම කියවා ඇති අතර w3c නිර්දේශයෙන් හරස් ප්‍රභව සම්පත් බෙදාගැනීම කියවීමට උත්සාහ කර ඇත්තෙමි

එක් දෙයක් ස්ථිරයි - මෙම ශීර්ෂකය භාවිතා කරන්නේ කෙසේදැයි මට තවමත් වැටහෙන්නේ නැත.

A සහ අඩවි B යන දෙඅංශයේම පූර්ණ පාලනය මා සතුව ඇත. මෙම වෙබ් අඩවියෙන් බාගත කර ඇති ජාවාස්ක්‍රිප්ට් කේතය මෙම ශීර්ෂකය භාවිතා කර B අඩවියේ සම්පත් වෙත ප්‍රවේශ වන්නේ කෙසේද?

පීඑස්

මට JSONP භාවිතා කිරීමට අවශ්‍ය නැත.

Access-Control-Allow-Originයනු CORS (හරස් සම්භවය සම්පත් දැන්වීම බෙදා ගන්න විද්යුත්) ශීර්ෂ .

අඩවි A වෙබ් අඩවියෙන් අන්තර්ගතය ලබා ගැනීමට උත්සාහ කරන විට Access-Control-Allow-Origin, මෙම පිටුවේ අන්තර්ගතය ඇතැම් මූලාරම්භයන්ට ප්‍රවේශ විය හැකි බව බ්‍රව්සරයට පැවසීමට අඩවි B ට ප්‍රතිචාර ශීර්ෂයක් යැවිය හැකිය . (ක සම්භවය වන්නේ වසම, ප්ලස් යෝජනා ක්රමය සහ තොට අංකය .) සුපුරුදු පරිදි, අඩවිය බී ගේ පිටු වෙනත් ඕනෑම සම්භවය ප්රවේශ විය නොහැකි , Access-Control-Allow-Originශීර්ෂකය භාවිතා කිරීමෙන් නිශ්චිත ඉල්ලීම් සම්භවයක් මඟින් හරස් සම්භවය සඳහා දොරක් විවෘත වේ.

අඩවි A වෙත ප්‍රවේශ වීමට වෙබ් අඩවියට අවශ්‍ය සෑම සම්පතක් / පිටුවක් සඳහාම, අඩවි බී ප්‍රතිචාර ශීර්ෂය සමඟ එහි පිටු සේවය කළ යුතුය:

Access-Control-Allow-Origin: http://siteA.com

නවීන බ්‍රව්සර් හරස් වසම් ඉල්ලීම් සම්පූර්ණයෙන්ම අවහිර නොකරනු ඇත. අඩවි A වෙබ් අඩවියෙන් පිටුවක් ඉල්ලා සිටියහොත්, බ්‍රව්සරය ඇත්ත වශයෙන්ම ජාල මට්ටමින් ඉල්ලූ පිටුව ලබා ගන්නා අතර ප්‍රතිචාර ශීර්ෂයන් අඩවි A අවසර ලත් ඉල්ලුම් වසමක් ලෙස ලැයිස්තුගත කරන්නේ දැයි පරීක්ෂා කරයි. අඩවිය බී අඩවිය මෙම පිටුව වෙත ප්රවේශ වීමට ඉඩ ඇති බව පෙන්නුම් කර නැත නම්, බ්රවුසරය පුපුරවා හරිනු ඇත XMLHttpRequestගේ errorඅවස්ථාව සහ ඉල්ලා JavaScript කේතයෙහි ප්රතිචාරය දත්ත ප්රතික්ෂේප කරනවා.

සරල නොවන ඉල්ලීම්

ජාල මට්ටමින් සිදුවන දේ ඉහත විස්තර කර ඇති ප්‍රමාණයට වඩා තරමක් සංකීර්ණ විය හැකිය . ඉල්ලීම "සරල නොවන" ඉල්ලීමක් නම් , බ්‍රව්සරය මුලින්ම දත්ත-අඩු "පෙර-ආලෝකය" විකල්ප ඉල්ලීමක් යවයි, සේවාදායකයා එම ඉල්ලීම පිළිගන්නේද යන්න තහවුරු කර ගැනීම සඳහා. (හෝ දෙකම) ඉල්ලීමක් සරල නොවේ:

• GET හෝ POST හැර වෙනත් HTTP ක්‍රියාපදයක් භාවිතා කිරීම (උදා: PUT, DELETE)
• සරල නොවන ඉල්ලීම් ශීර්ෂ භාවිතා කිරීම; එකම සරල ඉල්ලීම් ශීර්ෂයන් වන්නේ:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type(මෙම පමණක් සරල එහි අගය වන විට application/x-www-form-urlencoded, multipart/form-dataහෝ text/plain)

සරල නොවන ක්‍රියාපද හා / හෝ Access-Control-Allow-Headersසරල නොවන ශීර්ෂයන්ට ගැලපෙන සුදුසු ප්‍රතිචාර ශීර්ෂයන් ( සරල නොවන ශීර්ෂයන් Access-Control-Allow-Methodsසඳහා , සරල නොවන ක්‍රියා පද සඳහා) සේවාදායකයා OPTIONS පූර්ව ආලෝකයට ප්‍රතිචාර දක්වන්නේ නම්, බ්‍රව්සරය සත්‍ය ඉල්ලීම යවයි.

/somePageසරල නොවන Content-Typeඅගයක් සහිතව application/json, වෙබ් අඩවිය A සඳහා PUT ඉල්ලීමක් යැවීමට අවශ්‍ය යැයි සිතමු , බ්‍රව්සරය මුලින්ම පූර්ව ආලෝක ඉල්ලීමක් යවනු ඇත:

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

බව සටහන Access-Control-Request-Methodහා Access-Control-Request-Headersස්වයංක්රීයව බ්රව්සරය විසින් එකතු ඇත; ඔබට ඒවා එකතු කිරීමට අවශ්‍ය නැත. මෙම විකල්ප පෙරදසුනට සාර්ථක ප්‍රතිචාර ශීර්ෂයන් ලැබේ:

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

සත්‍ය ඉල්ලීම යවන විට (පූර්ව ආලෝකකරණය සිදු කිරීමෙන් පසු), හැසිරීම සරල ඉල්ලීමක් හසුරුවන ආකාරය හා සමාන වේ. වෙනත් වචන වලින් කිවහොත්, පෙර-ආලෝකය සාර්ථක වූ සරල නොවන ඉල්ලීමක් සරල ඉල්ලීමක් ලෙස සලකනු ලැබේ (එනම්, සේවාදායකයා Access-Control-Allow-Originසත්‍ය ප්‍රතිචාරය සඳහා නැවත යැවිය යුතුය ).

බ්‍රව්සර් සත්‍ය ඉල්ලීම යවයි:

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

Access-Control-Allow-Originසරල ඉල්ලීමක් සඳහා සේවාදායකයා එය ආපසු යවයි :

Access-Control-Allow-Origin: http://siteA.com

සරල නොවන ඉල්ලීම් පිළිබඳ වැඩි විස්තර සඳහා CORS හරහා XMLHttpRequest තේරුම් ගැනීම බලන්න .

හරස්-ප්‍රභව සම්පත් බෙදාගැනීම - CORS(AKA Cross-Domain AJAX ඉල්ලීම) බොහෝ වෙබ් සංවර්ධකයින්ට මුහුණ දිය හැකි ගැටළුවක් වන අතර, එකම-මූලාරම්භය-ප්‍රතිපත්තියට අනුව, බ්‍රව්සර් සේවාදායක ජාවාස්ක්‍රිප්ට් ආරක්‍ෂිත වැලිපිල්ලක සීමා කරයි, සාමාන්‍යයෙන් JS හට දුරස්ථ සේවාදායකයක් සමඟ කෙලින්ම සන්නිවේදනය කළ නොහැක. වෙනත් වසමකින්. අතීතයේ දී සංවර්ධකයින් හරස් වසම් සම්පත් ඉල්ලීම සාක්ෂාත් කර ගැනීම සඳහා බොහෝ උපක්‍රමශීලී ක්‍රම නිර්මාණය කළ අතර, බොහෝ විට භාවිතා කරන ක්‍රම:

1. දුරස්ථව සන්නිවේදනය කිරීම සඳහා "ප්‍රොක්සියක්" ලෙස ෆ්ලෑෂ් / සිල්වර් ලයිට් හෝ සේවාදායක පැත්ත භාවිතා කරන්න.
2. JSON With Padding ( JSONP ).
3. දුරස්ථ සේවාදායකය iframe එකක කාවැද්දූ අතර කැබැල්ල හෝ කවුළුව හරහා සන්නිවේදනය කරන්න , මෙහි යොමු වන්න .

එම උපක්‍රමශීලී ක්‍රමවලට අඩු හෝ වැඩි වශයෙන් ගැටළු කිහිපයක් ඇත, නිදසුනක් ලෙස සංවර්ධකයින් එය සරලව “එවාල්” කළහොත් JSONP ආරක්ෂක වළකට හේතු විය හැකි අතර, ඉහත # 3, එය ක්‍රියාත්මක වුවද, වසම් දෙකම එකිනෙකා අතර දැඩි ගිවිසුමක් ගොඩනගා ගත යුතුය, එය නම්‍යශීලී හෝ අලංකාර නොවේ IMHO:)

W3C විසින් මෙම ගැටළුව විසඳීම සඳහා ආරක්ෂිත, නම්‍යශීලී සහ නිර්දේශිත සම්මත ක්‍රමයක් සැපයීම සඳහා සම්මත විසඳුමක් ලෙස හරස් ප්‍රභව සම්පත් බෙදාගැනීම (CORS) හඳුන්වා දී ඇත.

යාන්ත්‍රණය

ඉහළ මට්ටමේ සිට අපට සරලවම සිතිය හැක්කේ CORS යනු A වසමේ සේවාදායක AJAX ඇමතුම සහ B වසමේ සත්කාරක පිටුවක් අතර ගිවිසුමක් වන අතර සාමාන්‍ය හරස් ප්‍රභව ඉල්ලීමක් / ප්‍රතිචාරයක් වනුයේ:

DomainA AJAX ඉල්ලීම් ශීර්ෂයන්

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

වසම් බී ප්‍රතිචාර ශීර්ෂයන්

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

මා ඉහත සලකුණු කළ නිල් පැහැති කොටස් කර්නල් කරුණු වන අතර, "සම්භවය" ඉල්ලීම් ශීර්ෂය "මඟින් හරස් සම්භව ඉල්ලීම හෝ පූර්ව ආලෝක ඉල්ලීම ආරම්භ වන්නේ කොතැනින්ද යන්න දක්වයි", "ප්‍රවේශ-පාලනය-ඉඩ දෙන්න-සම්භවය" ප්‍රතිචාර ශීර්ෂය මඟින් මෙම පිටුව දුරස්ථ ඉල්ලීමට ඉඩ දෙයි DomainA (අගය * නම් * ඕනෑම වසමකින් දුරස්ථ ඉල්ලීම් වලට ඉඩ දෙයි).

මා ඉහත සඳහන් කළ පරිදි, ඇත්ත වශයෙන්ම හරස් සම්භවයක් ඇති HTTP ඉල්ලීම ඉදිරිපත් කිරීමට පෙර " පූර්ව ආලෝක ඉල්ලීමක් " ක්‍රියාත්මක කිරීමට W3 නිර්දේශ කර ඇත, කෙටියෙන් කිවහොත් එය HTTP OPTIONSඉල්ලීමකි:

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Foo.aspx OPTIONS HTTP ක්‍රියාපදයට සහය දක්වන්නේ නම්, එය පහත පරිදි ප්‍රතිචාර දැක්විය හැකිය:

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

ප්‍රතිචාරයේ "ප්‍රවේශ-පාලක-ඉඩ දෙන්න-සම්භවය" සහ එහි වටිනාකම "*" හෝ CORS ඉල්ලීම ඉදිරිපත් කළ වසම අඩංගු වන්නේ නම් පමණි, මෙම අනිවාර්ය කොන්දේසිය තෘප්තිමත් කිරීමෙන් බ්‍රව්සරය සත්‍ය හරස් වසම් ඉල්ලීම ඉදිරිපත් කර ප්‍රති result ලය හැඹිලිය. " Preflight-Result-Cache " හි.

මම මීට වසර තුනකට පෙර CORS ගැන බ්ලොග් කළෙමි: AJAX Cross-Origin HTTP ඉල්ලීම

ප්‍රශ්නයට පිළිතුරු දීමට තරමක් පරණ ය, නමුත් මෙම ප්‍රශ්නය පිළිබඳ අනාගත සඳහනක් සඳහා මම මෙය පළ කරමි.

අනුව මෙම මොසිල්ලා සංවර්ධක ජාලය ලිපිය,

සම්පතක් වෙනත් වසමකින් හෝ වරායකින් පළමු සම්පත සේවය කරන ස්ථානයට වඩා සම්පතක් ඉල්ලා සිටින විට හරස් සම්භවයක් ඇති HTTP ඉල්ලීමක් කරයි.

ක HTML පිටුව සිට සේවය http://domain-a.comවර්ගයන් ඉතා <img>සඳහා src ඉල්ලීම http://domain-b.com/image.jpg.
අද වෙබයේ බොහෝ පිටු CSS ස්ටයිල් ෂීට් , රූප සහ ස්ක්‍රිප්ට් වැනි සම්පත් වෙනම වසම් වලින් පටවනු ලැබේ (එබැවින් එය සිසිල් විය යුතුය).

එකම මූලාරම්භක ප්‍රතිපත්තිය

ආරක්ෂක හේතූන් මත, ස්ක්‍රිප්ට් තුළ සිට ආරම්භ කරන ලද හරස් ප්‍රභව HTTP ඉල්ලීම් බ්‍රව්සර් සීමා කරයි . උදාහරණයක් ලෙස, සහ අනුගමනය කරන එකම සම්භවයක් ප්රතිපත්තිය . ඒ නිසා, භාවිතා කර වෙබ් යෙදුම හෝ පමණක් බවට පත් විය හැකි HTTP ඉල්ලීම් කිරීමට තමන්ගේ ම වසම .
XMLHttpRequestFetch
XMLHttpRequestFetch

හරස් ප්‍රභව සම්පත් බෙදාගැනීම (CORS)

වෙබ් යෙදුම් වැඩි දියුණු කිරීම සඳහා, සංවර්ධකයින් බ්‍රව්සර් වෙළෙන්දන්ගෙන් හරස් වසම් ඉල්ලීම් වලට ඉඩ දෙන ලෙස ඉල්ලා සිටියහ.

මෙම හරස් සම්භවය සම්පත් දැන්වීම බෙදා ගන්න විද්යුත් (CORS) යාන්ත්රණයක් වෙබ් සේවාදායක දෙන තරණය-වසම ප්රවේශ පාලනය සුරක්ෂිත හරස් වසම, දත්ත හුවමාරු සලසන.
නවීන බ්‍රව්සර් API බහාලුමක් තුළ CORS භාවිතා කරයි - වැනි හෝXMLHttpRequestFetch හරස් සම්භවය HTTP ඉල්ලීම් අවදානම් තත්ත්වයන් අවම කිරීම සඳහා -.

CORS ක්‍රියා කරන ආකාරය ( Access-Control-Allow-Originශීර්ෂකය)

විකිපීඩියා :

CORS ප්‍රමිතිය මඟින් නව HTTP ශීර්ෂයන් විස්තර කරන අතර එමඟින් බ්‍රව්සර් සහ සේවාදායකයන්ට දුරස්ථ URL ඉල්ලීමට අවසර ඇති විට පමණක් ඉල්ලුම් කළ හැකිය.

සමහර වලංගු කිරීම් සහ අවසරයන් සේවාදායකයාට කළ හැකි වුවද, සාමාන්‍යයෙන් මෙම ශීර්ෂයන්ට සහය දැක්වීම සහ ඔවුන් පනවා ඇති සීමාවන්ට ගරු කිරීම බ්‍රව්සරයේ වගකීම වේ.

උදාහරණයක්

1. බ්‍රව්සරය OPTIONSඉල්ලීම යවන්නේ aOrigin HTTP ශීර්ෂයක් .

   මෙම ශීර්ෂයේ වටිනාකම මව් පිටුවට සේවය කළ වසමයි. http://www.example.comපරිශීලකයෙකුගේ දත්ත වෙත ප්‍රවේශ වීමට උත්සාහ කරන පිටුවක් service.example.com, පහත ඉල්ලීම් ශීර්ෂය වෙත යවනු ලැබේ service.example.com:

   ආරම්භය: http://www.example.com

2. සේවාදායකයාට service.example.comප්‍රතිචාර දැක්විය හැක්කේ:

   • ක Access-Control-Allow-Originඅඩවි අවසර තිබෙන සම්භවය පෙන්නුම් එහි ප්රතිචාර (ACAO) ශීර්ෂ.
     උදාහරණයක් වශයෙන්:

     Access-Control-Allow-Origin: http://www.example.com

   • හරස් සම්භව ඉල්ලීමට සේවාදායකයා ඉඩ නොදෙන්නේ නම් දෝෂ පිටුවක්

   • ක Access-Control-Allow-Originසියලු වසම් ඉඩ සලසා දෙන ආදේශක සමග (ACAO) ශීර්ෂ:

     Access-Control-Allow-Origin: *

මම CORS ගැන සිතීමට පටන් ගන්නා සෑම විටම, ඔබේ ප්‍රශ්නයේ විස්තර කර ඇති ආකාරයටම, ශීර්ෂ පා host සපයන්නේ කුමන වෙබ් අඩවියද යන්න පිළිබඳ මගේ බුද්ධිය වැරදිය. මට නම්, එය එකම මූල ප්‍රතිපත්තියේ අරමුණ ගැන සිතා බැලීමට උපකාරී වේ.

එකම මූලාරම්භක ප්‍රතිපත්තියේ පරමාර්ථය වන්නේ siteA.com හි අනිෂ්ට ජාවාස්ක්‍රිප්ට් වලින් ඔබව ආරක්ෂා කිරීමයි. ඔබ siteB.com සමඟ පමණක් බෙදා ගැනීමට තෝරාගත් පුද්ගලික තොරතුරු වෙත ප්‍රවේශ වීම. එකම මූල ප්‍රතිපත්තියක් නොමැතිව, siteA.com හි කතුවරුන් විසින් ලියන ලද ජාවාස්ක්‍රිප්ට් මඟින් ඔබේ බ්‍රව්සරයට siteB.com සඳහා ඉල්ලීම් කළ හැකිය, siteB.com සඳහා ඔබේ සත්‍යාපන කුකී භාවිතා කරමින්. මේ ආකාරයෙන්, siteA.com වෙත ඔබ siteB.com සමඟ බෙදාගන්නා රහස් තොරතුරු සොරකම් කළ හැකිය.

සමහර විට ඔබට හරස් වසම වැඩ කිරීමට අවශ්‍ය වේ, එය CORS පැමිණෙන්නේ කොතැනද යන්නයි Access-Control-Allow-Origin. com.

CORS ශීර්ෂයන්ට සේවය කළ යුත්තේ කුමන වසමද යන්න තේරුම් ගැනීමට, මෙය සලකා බලන්න. ඔබ malicious.com වෙත පිවිසෙන්න, එහි mybank.com වෙත හරස් වසම් ඉල්ලීමක් කිරීමට උත්සාහ කරන ජාවාස්ක්‍රිප්ට් කිහිපයක් අඩංගු වේ. අනිෂ්ට.කොම් වෙතින් ජාවාස්ක්‍රිප්ට් සමඟ අන්තර්ක්‍රියා කිරීමට ඉඩ දෙන එකම මූල ප්‍රතිපත්තිය ලිහිල් කරන CORS ශීර්ෂයන් සකසන්නේද නැද්ද යන්න තීරණය කිරීම අනිෂ්ට වෙබ් අඩවිය නොව mybank.com දක්වා විය යුතුය. අනිෂ්ට.කොම් හට තමන්ගේම ජාවාස්ක්‍රිප්ට් සඳහා mybank.com වෙත පිවිසීමට ඉඩ දෙන CORS ශීර්ෂයන් සැකසිය හැකි නම්, මෙය එකම මූල ප්‍රතිපත්තිය මුළුමනින්ම අහෝසි කරනු ඇත.

වෙබ් අඩවියක් සංවර්ධනය කිරීමේදී මගේ දෘෂ්ටි කෝණයෙන් මගේ නරක ප්‍රතිභාවට හේතුව මම සිතමි. එය මගේ ජාවාස්ක්‍රිප්ට් සමඟ මගේ වෙබ් අඩවියයි, එබැවින් එය ද්වේෂ සහගත කිසිවක් නොකරන අතර මගේ ජාවාස්ක්‍රිප්ට් සමඟ අන්තර්ක්‍රියා කළ හැකි වෙනත් වෙබ් අඩවි මොනවාද යන්න සඳහන් කිරීම මා සතු විය යුතුය . ඇත්ත වශයෙන්ම මම සිතන්නේ ජාවාස්ක්‍රිප්ට් මගේ වෙබ් අඩවිය සමඟ අන්තර් ක්‍රියා කිරීමට උත්සාහ කරන වෙනත් වෙබ් අඩවි මොනවාද සහ ඒවාට ඉඩ දීමට මම CORS භාවිතා කළ යුතුද?

1. සේවාදායකයෙක් http: // siteA වෙතින් javascript කේතය MyCode.js බාගත කරයි - ආරම්භය.

බාගත කරන කේතය - ඔබේ html ස්ක්‍රිප්ට් ටැගය හෝ ජාවාස්ක්‍රිප්ට් වෙතින් xhr හෝ වෙනත් ඕනෑම දෙයක් පැමිණියේ - http: // siteZ යැයි කියමු . තවද, බ්‍රව්සරය MyCode.js ඉල්ලූ විට, එය "සම්භවය: http: // siteZ " යනුවෙන් මූලාරම්භයක්: ශීර්ෂයක් යවයි , මන්ද ඔබ siteA සහ siteZ! = SiteA වෙත ඉල්ලීමක් කරන බව පෙනේ. (ඔබට මෙය නැවැත්වීමට හෝ බාධා කිරීමට නොහැකිය.)

2. MyCode.js හි ප්‍රතිචාර ශීර්ෂය තුළ Access-Control-Allow-Origin: http: // siteB අඩංගු වන අතර, එයින් අදහස් කළේ B වෙබ් අඩවියට හරස් සම්භවයක් ඇති සඳහනක් කිරීමට MyCode.js ට අවසර දී ඇති බවයි.

නැත. එහි තේරුම, මෙම ඉල්ලීම කිරීමට අවසර දී ඇත්තේ siteB ට පමණි. එබැවින් siteZ වෙතින් MyCode.js සඳහා වන ඔබගේ ඉල්ලීම වෙනුවට දෝෂයක් ඇති වන අතර බ්‍රව්සරය සාමාන්‍යයෙන් ඔබට කිසිවක් ලබා නොදේ. නමුත් ඔබ ඒ වෙනුවට ඔබේ සේවාදායකය ACAO: siteZ බවට පත් කළහොත් ඔබට MyCode.js ලැබෙනු ඇත. නැතහොත් එය '*' යවන්නේ නම්, එය ක්‍රියාත්මක වනු ඇත, එය සෑම කෙනෙකුටම ඇතුළුවීමට ඉඩ සලසයි. නැතහොත් සේවාදායකයා සෑම විටම මූලාරම්භය: ශීර්ෂකය වෙතින් නූල යවන්නේ නම් ... නමුත් ... ආරක්ෂාව සඳහා, ඔබ හැකර්වරුන්ට බිය වන්නේ නම් , ඔබේ සේවාදායකයා එම ඉල්ලීම් කිරීමට අවසර දී ඇති කෙටි ලැයිස්තුවක මූලාරම්භයට පමණක් ඉඩ දිය යුතුය.

එවිට, MyCode.js පැමිණෙන්නේ siteA වෙතින් ය. එය siteB වෙත ඉල්ලීම් කරන විට, ඒවා සියල්ලම හරස් සම්භවයක් ඇති අතර, බ්‍රව්සරය සම්භවය: siteA යවන අතර siteB විසින් siteA ලබා ගත යුතුය, එය අවසර ලත් ඉල්ලුම්කරුවන්ගේ කෙටි ලැයිස්තුවේ ඇති බව හඳුනාගෙන ACAO: siteA ආපසු එවන්න. එම ඉල්ලීම්වල ප්‍රති result ල ලබා ගැනීමට බ්‍රව්සරය ඔබගේ ස්ක්‍රිප්ටයට ඉඩ දෙන්නේ එවිට පමණි.

ඔබ PHP භාවිතා කරන්නේ නම්, php ගොනුවේ ආරම්භයේ දී පහත කේතය එක් කිරීමට උත්සාහ කරන්න:

ඔබ localhost භාවිතා කරන්නේ නම්, මෙය උත්සාහ කරන්න:

header("Access-Control-Allow-Origin: *");

ඔබ සේවාදායකය වැනි බාහිර වසම් භාවිතා කරන්නේ නම්, මෙය උත්සාහ කරන්න:

header("Access-Control-Allow-Origin: http://www.website.com");

ප්‍රතික්‍රියා සහ ඇක්සියෝස් භාවිතා කරමින් , URL වෙත ප්‍රොක්සි සබැඳියට සම්බන්ධ වී පහත පෙන්වා ඇති පරිදි ශීර්ෂකය එක් කරන්න

https://cors-anywhere.herokuapp.com/ + Your API URL

ප්‍රොක්සි සබැඳිය එක් කිරීමෙන් පමණක් ක්‍රියා කරනු ඇත, නමුත් එය නැවත ප්‍රවේශය සඳහා දෝෂයක් ඇති කළ හැකිය. එබැවින් පහත පෙන්වා ඇති පරිදි ශීර්ෂකය එක් කිරීම වඩා හොඳය.

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }

අවවාදයයි: නිෂ්පාදනයේදී භාවිතා නොකළ යුතුය

මෙය ඉක්මන් විසඳුමක් පමණි, ඔබට ප්‍රතිචාරයක් ලබා ගැනීමට නොහැකි වීමට හේතුව සමඟ ඔබ අරගල කරන්නේ නම්, ඔබට මෙය භාවිතා කළ හැකිය. නමුත් නැවතත් එය නිෂ්පාදනය සඳහා හොඳම පිළිතුර නොවේ.

පහත වැටීම් කිහිපයක් ඇති අතර එය සම්පූර්ණයෙන්ම අර්ථවත් කරයි, මම බොහෝ කලකට පෙර අනතුරු ඇඟවීම එකතු කළ යුතුව තිබුණි.

ඔබගේ ඉල්ලීම බ්‍රවුසරය අවහිර කරන හරස් ඩොමේන් යෙදුමක් පරීක්ෂා කිරීමට ඔබට අවශ්‍ය නම්, ඔබට ඔබගේ බ්‍රව්සරය අනාරක්ෂිත ආකාරයෙන් විවෘත කර ඔබගේ කේතය වෙනස් නොකර ඔබේ කේතය අනාරක්ෂිත නොකර ඔබගේ යෙදුම පරීක්ෂා කළ හැකිය. MAC මෙහෙයුම් පද්ධතියෙන් ඔබට මෙය පර්යන්ත රේඛාවෙන් කළ හැකිය:

open -a Google\ Chrome --args --disable-web-security --user-data-dir

මම සී express
්‍රගාමී 4 සහ නෝඩ් 7.4 සහ කෝණික සමඟ වැඩ කරමි. මට මේ සඳහා උපකාර කිරීමට මට ඇත්තේ එකම ගැටලුවකි: අ) සේවාදායක පාර්ශවය: app.js ගොනුවේදී මම සියලු ප්‍රතිචාර සඳහා ශීර්ෂ ලබා දෙමි:

app.use(function(req, res, next) {  
      res.header('Access-Control-Allow-Origin', req.headers.origin);
      res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
      next();
 });  

මෙය සියලු රවුටරයට පෙර තිබිය යුතුය .
මෙම ශීර්ෂයන් එකතු කර ඇති බව මම දුටුවෙමි:

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

නමුත් මට එය අවශ්‍ය නැත,
ආ) සේවාදායකයාගේ පැත්ත: අජැක්ස් යැවීමේදී ඔබට එකතු කිරීම අවශ්‍ය වේ: "withCredentials: true," වැනි:

$http({
     method: 'POST',
     url: 'url, 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

වාසනාව.

මගේ අත්දැකීම් අනුව, CORS පවා සැලකිලිමත් වන්නේ මන්දැයි සරල පැහැදිලි කිරීමක් සොයා ගැනීම දුෂ්කර ය.

එය එහි ඇත්තේ මන්දැයි ඔබ තේරුම් ගත් පසු, ශීර්ෂයන් සහ සාකච්ඡාව වඩාත් පැහැදිලි වේ. මම එයට පේළි කිහිපයකින් පහරක් දෙන්නම්.

ඒ සියල්ල කුකීස් ගැන ය. කුකීස් ඔවුන්ගේ වසම අනුව සේවාදායකයෙකු මත ගබඩා කර ඇත.

උදාහරණ කතාවක්: ඔබේ පරිගණකයේ කුකියක් තිබේ yourbank.com. සමහර විට ඔබේ සැසිය එහි තිබේ.

ප්‍රධාන කරුණ: සේවාදායකයා සේවාදායකයා වෙත ඉල්ලීමක් කළ විට, එය සේවාදායකයා සිටින වසම යටතේ ගබඩා කර ඇති කුකි යවනු ඇත.

ඔබ ඔබගේ බ්‍රව්සරයට පිවිසී ඇත yourbank.com. ඔබගේ සියලු ගිණුම් බැලීමට ඔබ ඉල්ලා සිටී. yourbank.comකුකීස් ගොඩවල් ලබාගෙන එහි ප්‍රතිචාරය (ඔබගේ ගිණුම්) ආපසු යවයි.

වෙනත් සේවාදායකයෙක් සේවාදායකයකු වෙත හරස් ප්‍රභව ඉල්ලීමක් කළහොත් , එම කුකීස් පෙර මෙන් යවනු ලැබේ. රුහ් රෝ.

ඔබ ගවේෂණය කරන්න malicious.com. අනිෂ්ට ඇතුළුව විවිධ බැංකුවලට ඉල්ලීම් රාශියක් ඉදිරිපත් yourbank.comකරයි.

කුකීස් අපේක්ෂිත පරිදි වලංගු බැවින්, සේවාදායකයා ප්‍රතිචාරයට අවසර දෙනු ඇත.

එම කුකීස් එක්රැස් කර යවනු ලැබේ - දැන්, malicious.comප්‍රතිචාරයක් ඇත yourbank.

අයියෝ.

දැන්, ප්රශ්න සහ පිළිතුරු කිහිපයක් පැහැදිලිව පෙනේ:

• "ඇයි අපි බ්‍රව්සරය එසේ කිරීමෙන් අවහිර නොකරන්නේ?" ඔව්. CORS.
• "අපි එය වටා යන්නේ කෙසේද?" CORS හරි යැයි සේවාදායකයා ඉල්ලීමට කියන්න.

හරස් සම්භවය බෙදාගැනීම සඳහා, ශීර්ෂකය සකසන්න: 'Access-Control-Allow-Origin':'*';

Php: header('Access-Control-Allow-Origin':'*');

නෝඩ්: app.use('Access-Control-Allow-Origin':'*');

විවිධ වසම් සඳහා අන්තර්ගතය බෙදා ගැනීමට මෙය ඉඩ දෙයි.

පයිතන්හිදී මම Flask-CORSපුස්තකාලය ඉතා සාර්ථක ලෙස භාවිතා කර ඇත්තෙමි . එය CORS සමඟ ගනුදෙනු කිරීම පහසු සහ වේදනා රහිත කරයි. මම පහත පුස්තකාල ලේඛනයෙන් කේත කිහිපයක් එකතු කළෙමි.

ස්ථාපනය කිරීම:

$ pip install -U flask-cors

සියලුම මාර්ගවල සියලුම වසම් සඳහා CORS ඉඩ දෙන සරල උදාහරණය:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/")
def helloWorld():
  return "Hello, cross-origin-world!"

වඩාත් නිශ්චිත උදාහරණ සඳහා ප්‍රලේඛනය බලන්න. මා විසින් ගොඩනඟන අයනික යෙදුමක CORS නිකුතුව වෙනම ෆ්ලැස්ක් සේවාදායකයකට ප්‍රවේශ විය යුතු ඉහත සරල උදාහරණය භාවිතා කර ඇත.

පහත දැක්වෙන කේතය ඔබේ වෙබ් කොන්ෆිග් ගොනුවේ අලවන්න.

සටහන් කර ඇති පරිදි, ඔබ පහත කේතය <system.webServer>ටැගය යටතේ ඇලවිය යුතුය

    <httpProtocol>  
    <customHeaders>  
     <add name="Access-Control-Allow-Origin" value="*" />  
     <add name="Access-Control-Allow-Headers" value="Content-Type" />  
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />  
    </customHeaders>  
  </httpProtocol>  

ප්‍රවේශය-පාලනය-ඉඩ දෙන්න-සම්භවය ප්‍රතිචාර ශීර්ෂය මඟින් ලබා දී ඇති මූලාරම්භයෙන් ඉල්ලීම් කේතය සමඟ ප්‍රතිචාරය බෙදා ගත හැකිද යන්න දක්වයි.

Header type Response       header
Forbidden header name      no

ඕනෑම ප්‍රභවයකින් කේතයකට සම්පතකට ප්‍රවේශ වීමට ඉඩ දෙන ලෙස බ්‍රව්සරයට පවසන ප්‍රතිචාරයකට පහත සඳහන් දේ ඇතුළත් වේ:

Access-Control-Allow-Origin: *

වැඩි විස්තර සඳහා මෙතැනට පිවිසෙන්න ....

Nginx සහ Appache

ඇප්සිලර් පිළිතුරට අමතරව, ඉල්ලීම සරලද නැද්ද යන්න පෙන්වන විකී ප්‍රස්ථාරයක් එක් කිරීමට මම කැමැත්තෙමි (සහ විකල්ප ගුවන් ගමන් පෙර ඉල්ලීම යවනු ලැබේද නැද්ද යන්න)

සරල ඉල්ලීම (උදා: සඳහා hotlinking රූප ) ඔබ, ඔබගේ සේවාදායකයේ මානකරන ගොනු වෙනස් කිරීමට (සේවාදායකය මත සත්කාරකත්වය දරනු ලබන උදා: PHP හි,) ඔහුගේ මෙල්වින් Guerrero සඳහන් වගේ අවශ්ය නැහැ නමුත් ඔබට යෙදුම ශීර්ෂ එකතු කල හැක පිළිතුර - එහෙත් මතක : ඔබ පූර්ණ එකතු නම් ඔබේ සේවාදායකයේ (වින්‍යාසය) ඇති කෝර්ස් ශීර්ෂයන් සහ ඒ සමඟම ඔබ යෙදුමේ සරල කෝර්ස් වලට ඉඩ දෙයි (උදා: php) මෙය කිසිසේත් ක්‍රියා නොකරනු ඇත.

ජනප්‍රිය සේවාදායක දෙකක් සඳහා වන වින්‍යාසයන් මෙහි දැක්වේ

• Nginx ( nginx.confගොනුව) මත CORS සක්‍රිය කරන්න

  කේත ස්නිපටය පෙන්වන්න

  location ~ ^/index\.php(/|$) {
     ...
      add_header 'Access-Control-Allow-Origin' "$http_origin" always; # if you change "$http_origin" to "*" you shoud get same result - allow all domain to CORS (but better change it to your particular domain)
      add_header 'Access-Control-Allow-Credentials' 'true' always;
      if ($request_method = OPTIONS) {
          add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above)
          add_header 'Access-Control-Allow-Credentials' 'true';
          add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days
          add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';  # arbitrary methods
          add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # arbitrary headers
          add_header 'Content-Length' 0;
          add_header 'Content-Type' 'text/plain charset=UTF-8';
          return 204;
      }
  }

  කේත ස්නිපටය ධාවනය කරන්නප්‍රති .ල සඟවන්න

  ස්නිපටය පුළුල් කරන්න

• සක්රිය කරන්න Appache මත CORS ( .htaccessගොනු)

  කේත ස්නිපටය පෙන්වන්න

  # ------------------------------------------------------------------------------
  # | Cross-domain Ajax requests                                                 |
  # ------------------------------------------------------------------------------
  
  # Enable cross-origin Ajax requests.
  # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
  # http://enable-cors.org/
  
  # change * (allow any domain) below to your domain
  Header set Access-Control-Allow-Origin "*"
  Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
  Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token"
  Header always set Access-Control-Allow-Credentials "true"

  කේත ස්නිපටය ධාවනය කරන්නප්‍රති .ල සඟවන්න

  ස්නිපටය පුළුල් කරන්න

කාටද පසුපෙළ පාලනය කළ නොහැක Options 405 Method Not Allowed.
ක්‍රෝම් බ්‍රව්සරය සඳහා වැඩ කිරීම.
විධාන රේඛාවෙන් ක්‍රියාත්මක කරන්න:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="path_to_profile"
උදාහරණය:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="C:\Users\vital\AppData\Local\Google\Chrome\User Data\Profile 2"