VPN-ന് CORS നിഷ്ക്രിയമാക്കാനാവില്ല, അത് പ്രതികരണം മാറ്റുന്നു
പുതിയ എക്സിറ്റ് വിലാസം രണ്ട് ഒറിജിനുകളെ ഒന്നാക്കുന്നില്ല. രണ്ട് പാതകളിലെയും പ്രതികരണ ഹെഡറുകൾ ശേഖരിച്ച് CORS-ന്റെ പ്രയോഗത്തെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് താരതമ്യം ചെയ്യുക.
ഒരേസമയം മാറിയ രണ്ട് കാര്യങ്ങൾ വേർതിരിച്ചുകൊണ്ട് തുടങ്ങുക: നെറ്റ്വർക്ക് പാതയും ബ്രൗസറിന്റെ പ്രയോഗവും. VPN എക്സിറ്റ് വിലാസം മാറ്റുന്നു; അത് പേജിന്റെ ഒറിജിൻ മാറ്റുന്നില്ല, അത് സ്കീം, ഹോസ്റ്റ്, പോർട്ട് എന്നിവകൊണ്ടാണ് നിർമ്മിക്കുന്നത്. അഭ്യർത്ഥന ഇപ്പോൾ വിജയിക്കുന്നുവെങ്കിൽ, പ്രതികരണത്തിൽ എന്തോ മാറി, അല്ലെങ്കിൽ അഭ്യർത്ഥന തന്നെ മാറി. ഏതാണെന്ന് കണ്ടെത്തുകയാണ് മുഴുവൻ അന്വേഷണം.
CORS ബ്രൗസർ പ്രയോഗിക്കുന്ന ഹെഡർ പ്രോട്ടോക്കോളാണ്, അതിനാൽ നെറ്റ്വർക്ക് പാതയിലെ ഒന്നിനും അത് നിഷ്ക്രിയമാക്കാനാവില്ല.
ഒറിജിൻ ഒരു IP വിലാസമല്ല
ഒറിജിൻ എന്നത് സ്കീം, ഹോസ്റ്റ്, പോർട്ട് എന്നിവയാണ്. പാക്കറ്റുകൾ പുറപ്പെടുന്ന വിലാസമല്ല അത്, സർവർ കാണുന്ന IP-യുമല്ല. അതുകൊണ്ടാണ് VPN എല്ലാ നിരീക്ഷിക്കാവുന്ന വിലാസവും മാറ്റിയിട്ടും ഒറിജിൻ അതേപടി നിർത്താൻ കഴിയുന്നത്. ബ്രൗസർ പ്രതികരണത്തിലെ Access-Control-Allow-Origin പേജിന്റെ ഒറിജിനുമായി താരതമ്യം ചെയ്യുന്നു, എക്സിറ്റ് വിലാസം ഒരിക്കലും ആ താരതമ്യത്തിൽ പ്രവേശിക്കുന്നില്ല.
അതിനാൽ CORS പിശക് ശരിയാക്കുന്നതായി തോന്നുന്ന എക്സ്റ്റൻഷനോ പ്രോക്സിയോ മറ്റെന്തോ ചെയ്യുന്നു: ഹെഡറുകൾ വീണ്ടും എഴുതുന്നു, അല്ലെങ്കിൽ അഭ്യർത്ഥന ഇനി ക്രോസ്-ഒറിജിൻ ആകാത്തവിധം റൂട്ട് ചെയ്യുന്നു. രണ്ടും VPN-ന്റെ സ്വഭാവമല്ല.
ബ്രൗസർ യഥാർത്ഥത്തിൽ അയക്കുന്നത്
ലളിതമല്ലാത്ത ക്രോസ്-ഒറിജിൻ അഭ്യർത്ഥനയ്ക്ക് ബ്രൗസർ ആദ്യം ഒരു പ്രീ-ഫ്ലൈറ്റ് OPTIONS അയക്കുന്നു, അത് ഉദ്ദേശിച്ച മെത്തേഡും ഹെഡറുകളും വഹിക്കുന്നു. സർവർ അനുവദിക്കുന്ന അനുമതികളോടെ മറുപടി നൽകണം, ആ മറുപടി നിയമങ്ങൾ പാലിച്ചാൽ മാത്രമേ യഥാർത്ഥ അഭ്യർത്ഥന തുടരൂ. VPN രണ്ട് കൈമാറ്റങ്ങളും വഹിക്കുന്ന പാത മാറ്റുന്നു, ഇടനില സേവനങ്ങൾ എന്ത് മറുപടി നൽകുന്നു എന്നതും മാറ്റാം. എന്നാൽ ഒറിജിൻ സ്ട്രിംഗോ പ്രീ-ഫ്ലൈറ്റ് വ്യവസ്ഥയോ അത് മാറ്റുന്നില്ല.
കമാൻഡ്-ലൈൻ ക്ലയന്റ് സാധാരണയായി അതിൽ ഒന്നും കാണിക്കുന്നില്ല. Origin ഹെഡർ അയക്കണമെന്നില്ല, പ്രീ-ഫ്ലൈറ്റ് പലപ്പോഴും ഒഴിവാക്കുന്നു, വ്യത്യസ്ത ക്രെഡൻഷ്യലുകൾ വഹിച്ചേക്കാം. curl-ന് തിരികെ നൽകിയ ബോഡി സർവർ curl-ന് മറുപടി നൽകി എന്ന് തെളിയിക്കുന്നു.
മാറിയ പ്രതികരണം കണ്ടെത്തുക
സ്റ്റാറ്റസ് കോഡ് മാത്രമല്ല, ഓരോ പാതയിലെയും യഥാർത്ഥ പ്രതികരണം താരതമ്യം ചെയ്യുക. CORS അനുമതികൾ വഹിക്കുന്ന ഹെഡറുകൾ, ഉള്ളടക്ക തരം, ഏതെങ്കിലും റീഡയറക്ട്, WAF അല്ലെങ്കിൽ CDN വേരിയന്റ് വേറെ പേജ് നിർമ്മിച്ചോ എന്നിവ നോക്കുക. പ്രാദേശിക നിരസനം, ഓതന്റിക്കേഷൻ റീഡയറക്ട്, അനുമതി-ഹെഡറില്ലാത്ത പിശക് പേജ് — എല്ലാം ബ്രൗസറിൽ പരാജയപ്പെടുന്നു, പക്ഷേ CORS ബഗ് പോലെ തോന്നുന്നു. അവ ഡെലിവറി-പാതയിലെ വ്യത്യാസങ്ങളാണ്, അവ തന്നെയാണ് രേഖപ്പെടുത്തേണ്ടത്.
രണ്ട് പാതകളിലെയും പ്രതികരണ ഹെഡറുകൾ ശേഖരിച്ച് വരി വരിയായി താരതമ്യം ചെയ്യുക. ഒരു പിശക് പേജിൽ Access-Control-Allow-Origin ഇല്ലാത്തത് മാത്രമാണ് വ്യത്യാസമെങ്കിൽ, കാരണം കണ്ടെത്തി.
പ്രയോഗമല്ല, സേവനം ശരിയാക്കുക
സേവനം നിങ്ങളുടേതാണെങ്കിൽ, അനുവദനീയ ഒറിജിനുകളും അഭ്യർത്ഥനയുടെ സവിശേഷതകളും വ്യക്തമായി പറയുക, തുടർന്ന് അതിന്റെ ഫ്രണ്ടെൻഡും ഇടനിലക്കാരും ഉണ്ടാക്കുന്ന പിശകുകൾ വായിക്കുക. അല്ലാത്തപക്ഷം സേവന ഉടമയ്ക്ക് ശുദ്ധീകരിച്ച താരതമ്യം അയക്കുക. ആ റിപ്പോർട്ടിൽ ഒരിക്കലും കുക്കികളോ അധികാര ഹെഡറുകളോ സെഷൻ കയറ്റുമതികളോ ഉൾപ്പെടുത്തരുത്, കാരണം നയം സംരക്ഷിക്കാൻ ഉദ്ദേശിക്കുന്നത് ആ ക്രെഡൻഷ്യലുകളെയാണ്.
CORS നിഷ്ക്രിയമാക്കുന്ന ബ്രൗസർ എക്സ്റ്റൻഷനുകൾ ഒഴിവാക്കുക. അവ സുരക്ഷാ അതിർത്തി മാറ്റുകയും വിശദീകരിക്കേണ്ട പ്രതികരണ-വ്യത്യാസം മറയ്ക്കുകയും ചെയ്യുന്നു, മറ്റെല്ലാ ഉപയോക്താക്കൾക്കും അതേ പരാജയം അവശേഷിപ്പിക്കുന്നു.
രണ്ട് പ്രതികരണങ്ങളും ഉപയോഗിച്ച ഒറിജിനും സഞ്ചരിച്ച പാതയും രേഖപ്പെടുത്തുക. ആ രേഖ VPN കിംവദന്തിയെ സേവന ബഗ്ഗാക്കി മാറ്റുന്നു.