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 en 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 dessa rubriker fungerar. I det här exemplet säger vi att vi har ett finansföretag som har implementerat Experience Cloud ID-tjänst på deras 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 skickar 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:
- Ursprung//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 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 godtycklig 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 XMLHttpRequest objektet behöver sin withCredentials egenskap inställd på true. 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 när en URL skickas som Ursprungger ID-tjänsten åtkomst till de nödvändiga resurserna.