વેબ બ્રાઉઝર સુરક્ષા મોડેલમાં ક્રોસ-ઓરિજિન રિસોર્સ શેરિંગ (CORS) નીતિઓ મહત્વપૂર્ણ ભૂમિકા ભજવે છે। જ્યારે કોઈ વેબ એપ્લિકેશન તેના પોતાના મૂળ (સ્કીમ, હોસ્ટ અને પોર્ટ) સિવાયના અન્ય સર્વર પરથી સંસાધનોની વિનંતી કરે છે, ત્યારે બ્રાઉઝર સુરક્ષા નિયમો લાગુ કરે છે। CORS તપાસનાર સાધન તમને એ સમજવામાં મદદ કરે છે કે શું વેબ બ્રાઉઝર તમે પ્રદાન કરેલા HTTP પ્રતિસાદ હેડરો અને તમારી વિનંતીની વિગતોના આધારે ચોક્કસ ક્રોસ-ઓરિજિન વિનંતીને મંજૂરી આપશે કે નહીં।
આ સાધન સંપૂર્ણપણે તમારા બ્રાઉઝરમાં કામ કરે છે। તમારા હેડરો અને વિનંતી વિગતો તમારા બ્રાઉઝરમાં રહે છે। BroBroGo દ્વારા કંઈપણ અપલોડ અથવા સાચવવામાં આવ્યું નથી।
CORS નીતિ અને Access-Control-Allow-Origin ની ભૂમિકા
CORS નીતિનું મુખ્ય ઘટક Access-Control-Allow-Origin હેડર છે। આ હેડર નક્કી કરે છે કે કયા મૂળને સંસાધન મેળવવાની મંજૂરી છે।
જ્યારે તમે આ સાધનમાં વિગતો તપાસો છો, ત્યારે બ્રાઉઝર નિર્ણય નીચેના નિયમોના આધારે નક્કી થાય છે:
- જો હેડર વિનંતી કરેલા મૂળ સાથે બરાબર મેળ ખાય છે, તો સાધન "Access-Control-Allow-Origin બરાબર ‹origin› સાથે મેળ ખાય છે." દર્શાવે છે।
- જો હેડર વાઇલ્ડકાર્ડ ધરાવે છે અને ઓળખપત્રો શામેલ નથી, તો તે "Access-Control-Allow-Origin આ વિનંતી માટે કોઈપણ મૂળની મંજૂરી આપે છે." તરીકે ઓળખાય છે।
- જો આ હેડર ગેરહાજર હોય, તો નિર્ણય "Access-Control-Allow-Origin ખૂટે છે." સાથે અવરોધિત થાય છે।
- જો હેડરનું મૂલ્ય અપેક્ષિત મૂળ સાથે મેળ ખાતું નથી, તો સાધન "Access-Control-Allow-Origin
‹actual›છે,‹expected›નથી." દર્શાવે છે। - જો હેડરમાં અલ્પવિરામથી અલગ કરેલા બહુવિધ મૂલ્યો હોય, તો તેને અમાન્ય ગણવામાં આવે છે અને સાધન "Access-Control-Allow-Origin પાસે અમાન્ય મૂલ્ય છે:
‹value›." દર્શાવે છે।
ઓળખપત્રો અને Access-Control-Allow-Credentials નો પ્રભાવ
જ્યારે વિનંતીમાં કૂકીઝ અથવા HTTP પ્રમાણીકરણ જેવા ઓળખપત્રો શામેલ હોય, ત્યારે CORS નીતિના નિયમો વધુ કડક બને છે।
આ કિસ્સામાં નીચેના વિશિષ્ટ નિયમો લાગુ થાય છે:
- વાઇલ્ડકાર્ડ પર પ્રતિબંધ: જ્યારે ઓળખપત્રો શામેલ હોય ત્યારે
Access-Control-Allow-Originનું મૂલ્ય વાઇલ્ડકાર્ડ*હોઈ શકતું નથી। જો આવું હોય, તો સાધન "જ્યારે ઓળખપત્રો શામેલ હોય ત્યારે Access-Control-Allow-Origin * ન હોઈ શકે." તેવો નિર્ણય આપશે। - સ્પષ્ટ ઓળખપત્ર મંજૂરી: ઓળખપત્ર ધરાવતી વિનંતીઓ માટે
Access-Control-Allow-Credentialsહેડર બરાબરtrueહોવું આવશ્યક છે। જો તે હાજર અને સાચું હોય, તો સાધન "Access-Control-Allow-Credentials બરાબર સાચું છે." દર્શાવે છે। જો તે ખૂટે છે, તો "ઓળખપત્રની વિનંતી માટે Access-Control-Allow-Credentials: સાચું." ની જરૂરિયાત દર્શાવવામાં આવે છે। - બિન-ઓળખપત્ર વિનંતીઓ: જો વિનંતીમાં ઓળખપત્રો શામેલ ન હોય, તો સાધન "ઓળખપત્ર શામેલ નથી, તેથી Access-Control-Allow-Credentials આ નિર્ણયને અસર કરતું નથી." તેવો નિર્ણય લે છે।
પ્રીફ્લાઇટ વિનંતીઓ: પદ્ધતિઓ અને હેડરોની મંજૂરી
જટિલ વિનંતીઓ માટે બ્રાઉઝર વાસ્તવિક વિનંતી મોકલતા પહેલા એક OPTIONS વિનંતી મોકલે છે, જેને પ્રીફ્લાઇટ વિનંતી કહેવામાં આવે છે। આ પ્રક્રિયામાં Access-Control-Allow-Methods અને Access-Control-Allow-Headers ની ભૂમિકા મહત્વની છે।
વિનંતી કરેલ પદ્ધતિઓ (Methods)
- જો પદ્ધતિ CORS-સલામત (CORS-safelisted) હોય, તો તેને હેડરમાં સૂચિબદ્ધ કરવાની જરૂર નથી। સાધન દર્શાવશે કે "
‹method›એ CORS-સલામત પદ્ધતિ છે અને તેને Access-Control-Allow-Methods માં દેખાવાની જરૂર નથી."। - અન્ય પદ્ધતિઓ માટે, જો પ્રીફ્લાઇટ પ્રતિસાદ તેને મંજૂરી આપે છે, તો સાધન "પ્રીફ્લાઇટ
‹method›પરવાનગી આપે છે." દર્શાવે છે। જો મંજૂરી ન હોય, તો "Access-Control-Allow-Methods‹method›ને મંજૂરી આપતું નથી." પ્રદર્શિત થાય છે।
વિનંતી કરેલ હેડરો (Headers)
- જો કોઈ વિનંતી કરેલ હેડર નામોને પ્રીફ્લાઇટ મંજૂરીની જરૂર ન હોય, તો સાધન "કોઈપણ વિનંતી કરેલ હેડર નામોને પ્રીફ્લાઇટ મંજૂરીની જરૂર છે." દર્શાવે છે।
- જો હેડરો મંજૂર હોય, તો "પ્રીફ્લાઇટ વિનંતી કરેલ હેડર નામોને પરવાનગી આપે છે:
‹headers›." પ્રદર્શિત થાય છે। - ઓળખપત્રો વિનાની વિનંતી માટે વાઇલ્ડકાર્ડ
*નો ઉપયોગ કરી શકાય છે, જે "Access-Control-Allow-Headers: * ઓળખપત્રો વિના વિનંતી માટે આ નામોને આવરી લે છે:‹headers›." તરીકે દર્શાવવામાં આવે છે। - Authorization હેડર માટે અપવાદ:
Authorizationહેડર હંમેશાAccess-Control-Allow-Headersમાં સ્પષ્ટ રીતે સૂચિબદ્ધ હોવું આવશ્યક છે। વાઇલ્ડકાર્ડ*તેને આવરી લેતું નથી। જો તે સ્પષ્ટ રીતે સૂચિબદ્ધ ન હોય, તો સાધન "Authorization સ્પષ્ટ રીતે સૂચિબદ્ધ હોવું આવશ્યક છે; Access-Control-Allow-Headers: * તેને આવરી લેતું નથી." ની ભૂલ દર્શાવે છે।
પ્રીફ્લાઇટ પ્રતિસાદોમાં HTTP સ્ટેટસ કોડનું મહત્વ
પ્રીફ્લાઇટ પ્રતિસાદની તપાસ કરતી વખતે, HTTP સ્ટેટસ લાઇન અત્યંત મહત્વપૂર્ણ છે।
- સફળ પ્રીફ્લાઇટ માટે પ્રતિસાદ 2xx સ્ટેટસ ધરાવતો હોવો જોઈએ। જો તે સફળ હોય, તો સાધન "પ્રીફ્લાઇટ સ્થિતિ
‹status›સફળ છે." દર્શાવે છે। - જો સ્ટેટસ કોડ 2xx શ્રેણીની બહાર હોય, તો "પ્રીફ્લાઇટ સ્ટેટસ
‹status›એ સફળ 2xx સ્ટેટસ નથી." દર્શાવવામાં આવે છે। - જો પ્રીફ્લાઇટ પ્રતિસાદમાં કોઈ HTTP સ્ટેટસ લાઇન પેસ્ટ કરવામાં ન આવી હોય, તો સાધન "કોઈ HTTP સ્થિતિ લાઇન પેસ્ટ કરવામાં આવી ન હતી, તેથી આવશ્યક 2xx પ્રીફ્લાઇટ સ્થિતિ તપાસી શકાતી નથી." દર્શાવે છે અને પરિણામ "હેડરો પસાર થાય છે, પરંતુ પ્રીફ્લાઇટ સ્થિતિ અજાણ છે." તરીકે ઓળખાય છે।
સાધનનો ઉપયોગ કેવી રીતે કરવો
આ સાધનનો ઉપયોગ કરવા માટે, તમારે નીચેના ઇનપુટ્સ પ્રદાન કરવાના રહેશે:
- તપાસ માટે પ્રતિભાવ: "વાસ્તવિક પ્રતિભાવ" અથવા "પ્રીફ્લાઇટ પ્રતિસાદ" માંથી પસંદ કરો।
- HTTP પ્રતિસાદ હેડરો: તમારા પ્રતિસાદ હેડરો પેસ્ટ કરો (મહત્તમ ૨,૦૦,૦૦૦ અક્ષરો)।
- મૂળની વિનંતી કરો: સ્કીમ, હોસ્ટ અને વૈકલ્પિક પોર્ટ દાખલ કરો (દા.ત.,
https://app.example.com)। તે માત્ર શુદ્ધ મૂળ હોવું જોઈએ, તેમાં પાથ અથવા ક્વેરી હોવી જોઈએ નહીં। - વિનંતી કરેલ પદ્ધતિ: HTTP પદ્ધતિ દાખલ કરો।
- હેડર નામોની વિનંતી કરી: અલ્પવિરામ અથવા નવી લાઇન દ્વારા અલગ કરેલા હેડર નામો દાખલ કરો।
- ઓળખપત્રો શામેલ કરો: જો વિનંતીમાં કૂકીઝ અથવા પ્રમાણીકરણ શામેલ હોય તો આ વિકલ્પ ચાલુ કરો।
ઇનપુટ સબમિટ કર્યા પછી, સાધન "પેસ્ટ કરેલ CORS પ્રતિસાદ દ્વારા મંજૂર." અથવા "પેસ્ટ કરેલ CORS પ્રતિસાદ દ્વારા અવરોધિત." જેવો સ્પષ્ટ બ્રાઉઝર નિર્ણય આપશે।
વારંવાર પૂછાતા પ્રશ્નો (FAQ)
શું મારે વાસ્તવિક પ્રતિભાવ અથવા પ્રીફ્લાઇટ પ્રતિસાદ પેસ્ટ કરવો જોઈએ?
બ્રાઉઝર કોડ એક પ્રતિભાવ વાંચી શકે છે કે કેમ તે તપાસવા માટે વાસ્તવિક પ્રતિસાદનો ઉપયોગ કરો। OPTIONS જવાબ માટે પ્રીફ્લાઇટ પ્રતિસાદનો ઉપયોગ કરો જે પછીની પદ્ધતિ અને તેના વિનંતી કરેલ હેડર નામોને મંજૂરી આપે છે।
ઓળખપત્ર સાથે વાઇલ્ડકાર્ડ કેમ નિષ્ફળ થઈ શકે છે?
જ્યારે કૂકીઝ અથવા HTTP પ્રમાણીકરણનો સમાવેશ કરવામાં આવે છે, ત્યારે મંજૂર મૂળ વિનંતીના મૂળ સાથે બરાબર મેળ ખાતો હોવો જોઈએ। મંજૂર પદ્ધતિઓ અને હેડરો માટેના વાઇલ્ડકાર્ડ્સ પણ તેમના વાઇલ્ડકાર્ડનો અર્થ ગુમાવે છે।
શું પાસ થવાનું પરિણામ સાબિત કરે છે કે લાઇવ વિનંતી કામ કરશે?
ના। આ પરિણામ ફક્ત પેસ્ટ કરેલ પ્રતિસાદ અને અહીં દાખલ કરેલ વિનંતી વિગતોને આવરી લે છે। રીડાયરેક્ટ્સ, કેશ્ડ પ્રતિસાદો, સર્વર નિયમોમાં ફેરફાર, બ્રાઉઝર એક્સ્ટેન્શન્સ અને પ્રીફ્લાઇટ પછી વાસ્તવિક પ્રતિસાદ હજુ પણ પરિણામ બદલી શકે છે।