CORS-stöd i Experience Cloud Identity Service cors-support-in-the-experience-cloud-id-service
Webbläsare använder Cross Origin Resource Sharing (CORS) för att begära resurser från en annan domän än den aktuella domänen. Experience Cloud Identity Service stöder CORS-standarder som möjliggör dessa serverförfrågningar på klientsidan. ID-tjänsten återgår till JSONP-begäranden i äldre webbläsare eller webbläsare som inte stöder CORS.
Problem med samma ursprung-principer och ID-serviceförfrågningar section-6608cf46d27143eeaeabacaa6aa14e8e
Principer för samma ursprung är säkerhetskontroller eller begränsningar som används av en webbläsare. När den används på den här nivån avgör webbläsaren själv om en begäran om resurser som skapats från en sida till en annan ska tillåtas eller blockeras. För att avgöra om en begäran är en begäran med samma ursprung jämför webbläsaren följande:
- URI (Uniform Resource Identifiers)
- Värdnamn (t.ex. http://www.my-webpage-example.com)
- Portnummer (t.ex. port 80 och 440 för HTTP- och HTTPS-begäranden)
Webbläsaren tillåter en begäran att lyckas om båda sidorna delar dessa egenskaper och blockerar resursbegäranden om de inte gör det.
CORS löser problem med principer med samma ursprung section-76c87ec3295d447bab220c84f138c235
CORS erbjuder ett säkert och effektivt sätt att begära resurser över olika domäner. CORS-specifikationen innehåller en uppsättning HTTP-rubriker som används i webbläsare för att skicka, ta emot och utvärdera resursbegäranden. Utvärderingen av en resursbegäran kallas preflight check. Med den här kontrollen kan webbläsare och servrar avgöra vilka begäranden som tillåts eller blockeras. Preflight-kontrollen är genomskinlig för programmet, API:t eller skriptet som begär en resurs. Två huvuden som är viktiga i resursförfrågningsprocessen är:
Origin: Ett begärandehuvud som identifierar källan för en begäran.Access-Control-Allow-Origin: Ett svarshuvud som anger om en resurs kan delas med den som gjorde begäran.
Låt oss titta på hur de här rubrikerna fungerar. I det här exemplet ska vi säga att vi har ett finansserviceföretag som har implementerat ID-tjänsten Experience Cloud på sin webbplats, www.finance-website.com. Följande tabell definierar hur CORS-begärande och svarshuvuden kontrollerar om det finns åtkomst till en resurs.
När finansföretagets sida läses in gör webbläsaren en begäran till dpm.demdex.net. Detta är ett anrop till domänen för de datainsamlingsservrar (DCS) som används av ID-tjänsten. Denna korsdomänbegäran innehåller rubriken:
- Origin//www.finance-website.com
Svaret från DCS-domänen innehåller följande rubriker som ger det finansiella företagets webbplats tillgång till nödvändiga resurser:
- Access-Control-Allow-origin: https://www.finance-website.com
- Access-Control-Allow-Credentials: true
Se även useCORSOnly.
Andra fördelar med att använda CORS section-6f44f30694c44f95bf9854b8a2af8449
Tabellen nedan beskriver några av de fördelar CORS ger kunder som använder ID-tjänsten.
CORS använder XMLHttpRequest för att begära och överföra data. Den här metoden är säkrare än en JSONP-begäran. Det säkerställer att det inte finns något sätt att köra godtyckliga JavaScript som kan finnas i svaret från DCS. CORS XMLHttpRequest-svarsnyttolasten tolkas av ID-tjänsten JavaScript och körs inte bara i en callback-funktion.
Obs! Om du vill acceptera cookies måste egenskapen withCredentials anges till true för objektet XMLHttpRequest . Den här egenskapen stöds i Chrome, Firefox, Internet Explorer (v10+), Opera och Safari.
CORS förbättrar prestanda eftersom:
- Webbläsaren hanterar resursbegäranden. Begärandeprocessen är transparent för ID-tjänsten.
- Till skillnad från asynkrona JSONP-begäranden avprioriterar inte webbläsaren CORS-begäranden och placerar dem i kö.
- ID-tjänsten svarar frivilligt. Detta innebär att när en URL som skickades som Origin, ger ID-tjänsten sidåtkomst till de nödvändiga resurserna.