Почему модуль IIS CORS 'Access-Control-Allow-Origin' кажется кэшированным? - PullRequest
Новая
       43

Почему модуль IIS CORS 'Access-Control-Allow-Origin' кажется кэшированным?

0 голосов
/ 18 мая 2018

Мы пытаемся получить доступ к файлу с перекрестным происхождением из JavaScript: 

var testImage = var Image;
testImage.crossOrigin = 'anonymous';
testImage.src = 'https://cdn.example.com/testImage.png';

в браузере (Chrome, но мы видим поведение в других браузерах и непосредственно через curl), отображая то же самоесодержание веб-страницы из трех разных доменов.Сервер изображений работает под управлением IIS, и на нем установлен модуль CORS со следующей конфигурацией: 

<cors enable="true" failUnlistedOrigins="true">
    <add origin="https://www.first_domain.com" allowed="true">
        <allowHeaders allowAllRequestedHeaders="true" />
    </add>
    <add origin="https://www.second_domain.com" allowed="true">
        <allowHeaders allowAllRequestedHeaders="true" />
    </add>
    <add origin="https://www.third_domain.com" allowed="true">
        <allowHeaders allowAllRequestedHeaders="true" />
    </add>
</cors>

Возможность блокировки или предоставления доступа зависит от времени и порядка доступа.Например, если мы получим доступ к изображению из https://www.first_domain.com,, значение заголовка Access-Control-Allow-Origin будет равно 'https://www.first_domain.com', и доступ будет предоставлен, но последующие попытки получить доступ к изображению из любого издва других разрешенных источника также приведут к тому, что значение заголовка Access-Control-Allow-Origin будет возвращено как 'https://www.first_domain.com', и, следовательно, доступ будет не предоставлен.

Если мыподождите четыре минуты или более, а затем попытайтесь получить доступ к изображению из https://www.second_domain.com,, тогда значение заголовка Access-Control-Allow-Origin будет возвращено как 'https://www.second_domain.com', и доступ будет предоставлен.Однако попытка получить доступ к изображению с https://www.first_domain.com впоследствии также приведет к тому, что значение заголовка Access-Control-Allow-Origin будет возвращено как 'https://www.second_domain.com', и доступ будет заблокирован.

Подождите еще четыре минуты, и https://www.third_domain.com (который до сих пор был заблокирован) получит доступ, а https://www.first_domain.com и https://www.second_domain.com будут заблокированы.Это похоже на то, как будто значение заголовка Access-Control-Allow-Origin кешируется в течение четырех минут на сервере изображений в первый раз, когда кто-то обращается к нему, и затем это же значение возвращается для всех доменов, запрашивающих доступ после этого, пока не истечет срок действия кэша.

Ответы [ 2 ]

0 голосов
/ 22 июня 2018

Вы можете использовать правила кэширования в IIS, чтобы игнорировать / исключать определенные заголовки для определенных расширений, либо через IIS Manager (с помощью функции кэширования вывода), либо непосредственно в файле web.config.В результате вы получите конфигурацию кэширования, похожую на: 

<caching enabled="true" enableKernelCache="true">
    <profiles>
        <add extension=".png" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" varyByHeaders="Access-Control-Allow-Origin" />
    </profiles>
</caching>

Очевидно, вы можете установить политику на любое недействительное значение;varByHeaders является ключевым элементом (разделяйте несколько имен заголовков точкой с запятой.) Некоторые операции, а именно аутентификация, плохо сочетаются с кэшем режима ядра, поэтому, если все остальное не работает, попробуйте отключить только режим ядра.

0 голосов
/ 21 мая 2018

Мне удалось обойти эту проблему, отключив кэш в web.config: 

<configuration>
   <sytem.webServer>
      <caching enabled="false" enableKernelCache="false" />
      ...
   </system.webServer>
</configuration>

Хотя все еще ищу лучшее решение.

...