வலை உலாவிகள் (Web browsers) பாதுகாப்பு காரணங்களுக்காக Cross-Origin Resource Sharing (CORS) கொள்கைகளைப் பின்பற்றுகின்றன. ஒரு குறிப்பிட்ட இணையப் பக்கத்திலிருந்து (Origin) மற்றொரு டொமைனில் உள்ள சர்வரை நோக்கி அனுப்பப்படும் கோரிக்கைகளை உலாவி அனுமதிக்குமா என்பதைத் தீர்மானிக்க CORS விதிகள் உதவுகின்றன. "CORS சரிபார்ப்பான்" கருவி, நீங்கள் வழங்கும் HTTP பதில் தலைப்புகள் மற்றும் கோரிக்கையின் விவரங்களை அடிப்படையாகக் கொண்டு, உலாவி அந்த குறிப்பிட்ட cross-origin கோரிக்கையை அனுமதிக்குமா அல்லது தடுக்குமா என்பதைத் துல்லியமாக பகுப்பாய்வு செய்து விளக்குகிறது.
CORS கொள்கையில் Access-Control-Allow-Origin-ன் பங்கு
CORS கொள்கையின் மிக முக்கியமான பகுதி Access-Control-Allow-Origin header ஆகும். ஒரு குறிப்பிட்ட இணையப் பக்கத்தின் குறியீடு (browser code), சர்வர் அனுப்பிய பதிலைப் படிக்க முடியுமா என்பதை இந்த header தான் தீர்மானிக்கிறது.
இந்தக் கருவி பின்வரும் விதிகளை அடிப்படையாகக் கொண்டு முடிவுகளை வழங்குகிறது:
- துல்லியமான பொருத்தம்: கோரிக்கை அனுப்பப்படும் Origin-உடன்
Access-Control-Allow-Originதுல்லியமாகப் பொருந்தினால், உலாவி கோரிக்கையை அனுமதிக்கும். அப்போது "Access-Control-Allow-Origin,‹origin›-உடன் துல்லியமாகப் பொருந்துகிறது." என்ற காரணம் காட்டப்படும். - பொதுவான அனுமதி (Wildcard): எந்தவொரு தளமும் அணுகும் வகையில்
*குறியீடு பயன்படுத்தப்பட்டால், "இந்த request-க்கு Access-Control-Allow-Origin எந்த Origin-ஐயும் அனுமதிக்கிறது." என்ற முடிவு பெறப்படும். - தவறான அல்லது விடுபட்ட மதிப்புகள்: இந்த header பதிலில் இல்லை என்றால், "Access-Control-Allow-Origin இல்லை." என்ற காரணத்துடன் கோரிக்கை தடுக்கப்படும். ஒருவேளை இந்த header-ல் கமாவால் பிரிக்கப்பட்ட பல மதிப்புகள் (comma-separated values) இருந்தால், அது தவறானதாகக் கருதப்பட்டு, "Access-Control-Allow-Origin-ன் value தவறானது:
‹value›." என்ற பிழை காட்டப்படும். - பொருந்தாமை: கோரப்பட்ட Origin-உடன் பொருந்தாதபோது, "Access-Control-Allow-Origin என்பது
‹actual›;‹expected›அல்ல." என்ற காரணம் காட்டப்படும்.
CORS Preflight கோரிக்கைகளில் Methods மற்றும் Headers-ன் செயல்பாடு
உலாவி சில வகையான கோரிக்கைகளை (உதாரணமாக, குறிப்பிட்ட HTTP methods அல்லது தனிப்பயன் headers கொண்டவை) நேரடியாக அனுப்பாது. அதற்குப் பதிலாக, OPTIONS முறையைப் பயன்படுத்தி ஒரு "Preflight" கோரிக்கையை அனுப்பி சர்வரின் அனுமதியைக் கோரும்.
HTTP Methods அனுமதி
Preflight கோரிக்கையின் போது, சர்வர் அனுமதிக்கும் முறைகள் Access-Control-Allow-Methods மூலம் சரிபார்க்கப்படுகின்றன.
GET,POSTபோன்ற CORS-safelisted முறைகளுக்கு இந்த அனுமதி தேவையில்லை. இதனால், "‹method›என்பது CORS safelisted method; அது Access-Control-Allow-Methods-ல் இருக்க வேண்டியதில்லை." என்ற முடிவு கிடைக்கும்.- பிற முறைகளுக்கு, "preflight,
‹method›-ஐ அனுமதிக்கிறது." அல்லது "Access-Control-Allow-Methods,‹method›-ஐ அனுமதிக்கவில்லை." என்ற முடிவுகள் காட்டப்படும். - உலாவிகள் தங்களின் பாதுகாப்பு விதிகள் காரணமாக சில குறிப்பிட்ட முறைகளை fetch கோரிக்கைகளில் அனுமதிக்காது. அவ்வாறு உள்ளிட்டால், "fetch requests-ல்
‹method›method-ஐ browsers அனுமதிக்காது." என்ற பிழை செய்தி தோன்றும்.
HTTP Headers அனுமதி
கோரிக்கையில் அனுப்பப்படும் தனிப்பயன் headers, Access-Control-Allow-Headers மூலம் சரிபார்க்கப்படுகின்றன.
- கோரப்பட்ட headers-க்கு அனுமதி தேவைப்படாதபோது, "கேட்கப்பட்ட header பெயர்கள் எதற்கும் preflight அனுமதி தேவையில்லை." என்று காட்டப்படும்.
- அனுமதி வழங்கப்பட்டிருந்தால், "கேட்கப்பட்ட header பெயர்களை preflight அனுமதிக்கிறது:
‹headers›." என்று வரும். - அனுமதி மறுக்கப்பட்டால், "Access-Control-Allow-Headers இவற்றை அனுமதிக்கவில்லை:
‹headers›." என்ற காரணம் காட்டப்படும்.
Credentials பயன்பாடும் அதன் தாக்கங்களும்
கோரிக்கைகளில் cookies அல்லது HTTP authentication போன்ற சான்றுகள் (Credentials) சேர்க்கப்படும்போது, CORS விதிகள் மிகவும் கடுமையானதாக மாறுகின்றன.
- Wildcard தடை: Credentials சேர்க்கப்படும்போது,
Access-Control-Allow-Originமதிப்பாக*குறியீட்டைப் பயன்படுத்த முடியாது. அவ்வாறு பயன்படுத்தினால், "Credentials சேர்க்கப்படும்போது Access-Control-Allow-Origin * ஆக இருக்க முடியாது." என்ற காரணத்துடன் கோரிக்கை தடுக்கப்படும். - துல்லியமான Credentials அனுமதி: சான்றுகளுடன் கூடிய கோரிக்கைகளுக்கு
Access-Control-Allow-Credentials: trueஎன்பது கட்டாயமாகும். இது துல்லியமாக அமைந்திருந்தால், "Access-Control-Allow-Credentials துல்லியமாக true ஆக உள்ளது." என்று காட்டப்படும். இல்லையெனில், "Credentials உள்ள request-க்கு Access-Control-Allow-Credentials: true தேவை." என்ற காரணத்துடன் கோரிக்கை தடுக்கப்படும். - தாக்கமின்மை: கோரிக்கையில் சான்றுகள் சேர்க்கப்படாதபோது, "Credentials சேர்க்கப்படவில்லை; எனவே இந்த முடிவை Access-Control-Allow-Credentials பாதிக்காது." என்ற முடிவு பெறப்படும்.
- Wildcard பொருளிழப்பு: Credentials சேர்க்கப்படும்போது, அனுமதிக்கப்பட்ட methods மற்றும் headers-ல் உள்ள wildcard (
*) குறியீடுகள் தங்களின் பொதுவான அனுமதிப் பொருளை இழக்கின்றன.
Authorization Header-க்கான சிறப்பு விதிகள்
CORS கொள்கையில் Authorization header மிகவும் தனித்துவமாகக் கையாளப்படுகிறது. Credentials இல்லாத கோரிக்கைகளில் Access-Control-Allow-Headers: * என்று குறிப்பிடுவது மற்ற அனைத்து headers-களையும் அனுமதிக்கும். ஆனால், Authorization header-க்கு இது பொருந்தாது.
Access-Control-Allow-Headers: * என்று குறிப்பிட்டிருந்தாலும், Authorization பெயர் அந்தப் பட்டியலில் வெளிப்படையாக (explicitly) எழுதப்பட்டிருக்க வேண்டும். இல்லையெனில், "Authorization வெளிப்படையாகப் பட்டியலிடப்பட வேண்டும்; Access-Control-Allow-Headers: * அதை உள்ளடக்காது." என்ற காரணத்துடன் கோரிக்கை தடுக்கப்படும்.
Preflight பதில்களில் HTTP Status Codes-ன் முக்கியத்துவம்
ஒரு Preflight (OPTIONS) கோரிக்கை வெற்றிகரமாக முடிவடைய, அதன் HTTP status code மிக முக்கியமானது.
- Preflight பதிலைச் சரிபார்க்கும்போது, அதன் status line-ஐயும் சேர்த்து ஒட்ட வேண்டும்.
- Status code வெற்றிகரமான 2xx பிரிவைச் சேர்ந்ததாக இருந்தால், "preflight status
‹status›வெற்றிகரமானது." என்று காட்டப்படும். - அது தோல்வியுற்றால், "preflight status
‹status›வெற்றிகரமான 2xx status அல்ல." என்று காட்டப்படும். - ஒருவேளை HTTP status line ஒட்டப்படாமல் இருந்தால், "HTTP status line ஒட்டப்படவில்லை; எனவே தேவையான 2xx preflight status-ஐச் சரிபார்க்க முடியாது." என்ற காரணத்துடன் முடிவு "indeterminate" (Headers சரியாக உள்ளன, ஆனால் preflight status தெரியவில்லை.) நிலைக்குச் செல்லும்.
உள்ளீட்டு விதிகள் மற்றும் பிழைகள்
CORS சரிபார்ப்பான் சரியாகச் செயல்பட, உள்ளீடுகள் குறிப்பிட்ட வடிவத்தில் இருக்க வேண்டும்:
| உள்ளீட்டுப் புலம் | விதிகள் மற்றும் வரம்புகள் | பிழைச் செய்திகள் |
|---|---|---|
| HTTP பதில் தலைப்புகள் | அதிகபட்சம் 200,000 எழுத்துகள் இருக்க வேண்டும். | * காலியாக இருந்தால்: "சரிபார்ப்பதற்கு முன் HTTP response headers-ஐ ஒட்டவும்."<br>* வரம்பை மீறினால்: "இந்த response வழக்கத்திற்கு மாறாகப் பெரியது. ‹max› எழுத்துகளுக்குள் வைத்திருக்கவும்."<br>* தவறான வரி: "வரி ‹line› சரியான HTTP header அல்லது status line அல்ல."<br>* தவறான பெயர்: "வரி ‹line›-ல் தவறான HTTP header பெயர் உள்ளது." |
| Request Origin | Scheme, host மற்றும் விருப்பமான port மட்டுமே இருக்க வேண்டும். URL path, query அல்லது credentials இருக்கக்கூடாது. (எ.கா: https://app.example.com) |
* "Scheme, host மற்றும் விருப்பமான port மட்டுமே கொண்ட Origin-ஐ உள்ளிடவும்; எடுத்துக்காட்டு: https://app.example.com." |
| கேட்கப்பட்ட method | சரியான HTTP method token ஆக இருக்க வேண்டும். | * "சரியான HTTP method token-ஐ உள்ளிடவும்." |
| கேட்கப்பட்ட header பெயர்கள் | கமா அல்லது தனித்தனி வரிகளால் பிரிக்கப்பட்ட சரியான பெயர்களாக இருக்க வேண்டும். | * "“‹header›” என்பது சரியான HTTP request header பெயர் அல்ல." |
ஏதேனும் பொதுவான உள்ளீட்டுப் பிழைகள் இருந்தால், "குறிக்கப்பட்ட input-ஐச் சரிசெய்து மீண்டும் முயலவும்." என்ற செய்தி காட்டப்படும்.
தனியுரிமை மற்றும் செயலாக்கம்
இந்தக் கருவியைப் பயன்படுத்தும்போது உங்கள் தனியுரிமை முழுமையாகப் பாதுகாக்கப்படுகிறது. நீங்கள் உள்ளிடும் HTTP headers மற்றும் கோரிக்கை விவரங்கள் அனைத்தும் உங்கள் கணினியில் உள்ள இணைய உலாவியிலேயே (browser) நேரடியாகச் செயலாக்கப்படுகின்றன. எந்தவொரு தரவும் BroBroGo சர்வர்களுக்கோ அல்லது வேறு எந்த இடத்திற்கோ பதிவேற்றப்படுவதோ அல்லது சேமிக்கப்படுவதோ இல்லை.
அடிக்கடி கேட்கப்படும் கேள்விகள் (FAQ)
Actual response-ஐ ஒட்ட வேண்டுமா அல்லது preflight response-ஐ ஒட்ட வேண்டுமா?
ஒரு response-ஐ browser code படிக்க முடியுமா என்று பார்க்க Actual response-ஐப் பயன்படுத்தவும். பின்னர் வரும் method மற்றும் கேட்ட header பெயர்களை அனுமதிக்கும் OPTIONS பதிலுக்கு Preflight response-ஐப் பயன்படுத்தவும்.
Credentials பயன்படுத்தும்போது wildcard ஏன் தோல்வியடையலாம்?
Cookies அல்லது HTTP authentication சேர்க்கப்பட்டால், அனுமதிக்கப்பட்ட Origin கோரிக்கையின் Origin-உடன் துல்லியமாகப் பொருந்த வேண்டும். அனுமதிக்கப்பட்ட methods மற்றும் headers-ல் உள்ள wildcard-களும் அவற்றின் wildcard பொருளை இழக்கும்.
அனுமதிக்கப்பட்ட முடிவு, live request வேலை செய்யும் என்பதை நிரூபிக்கிறதா?
இல்லை. இந்த முடிவு ஒட்டப்பட்ட response மற்றும் இங்கே உள்ளிடப்பட்ட request விவரங்களுக்கு மட்டுமே பொருந்தும். Redirects, cached responses, மாறும் server விதிகள், browser extensions மற்றும் preflight-க்குப் பிறகான actual response ஆகியவை முடிவை மாற்றலாம். மேலும், இந்தத் தளம் சர்வரைத் தொடர்புகொள்ளவோ, DNS/TLS சரிபார்க்கவோ அல்லது சர்வர் அமைப்புகளை மாற்றவோ செய்யாது.