Ошибка ImageProcessor/Windows Azure Storage, возвращает 403 Forbidden

Эти изображения могут быть загружены в локальный ENV, а также в производственный ENV. Однако ни по какой причине промежуточная среда не может их загрузить.

<package id="ImageProcessor" version="2.2.0.0" targetFramework="net45" />
  <package id="ImageProcessor.Web" version="4.2.1.0" targetFramework="net45" />
  <package id="ImageProcessor.Web.Config" version="2.2.0.0" targetFramework="net45" />
  <package id="ImageProcessor.Web.Plugins.AzureBlobCache" version="1.0.0.0" targetFramework="net45" />
  <package id="ImageProcessor.Web.PostProcessor" version="1.0.2.0" targetFramework="net45" />
  <package id="UmbracoAzureBlobStorageProvider" version="1.0.10.5" targetFramework="net45" />
  <package id="WindowsAzure.Storage" version="4.3.0" targetFramework="net45" />

Я использую ImageProcessor, и домены внесены в белый список по мере необходимости:

<whitelist>
        <add url="http://conceptjp.blob.core.windows.net/"/>
        <add url="https://az739977.vo.msecnd.net/"/>
</whitelist>

https://staging.conceptjp.com/remote.axd?https://az739977.vo.msecnd.net/media/6883/logo-sparitual.png?quality=70 (не работает)

https://conceptjp.com/remote.axd?https://az739977.vo.msecnd.net/media/6883/logo-sparitual.png?quality=70 (работает)

https://cjp.local/remote.axd?https://az739977.vo.msecnd.net/media/6883/logo-sparitual.png?quality=70 (работает, локальная среда)

2016-10-04 13:31:11.2393 Logging.TheLogger The remote server returned an error: (403) Forbidden. The remote server returned an error: (403) Forbidden.    at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.EndExecuteAsync[T](IAsyncResult result)
   at Microsoft.WindowsAzure.Storage.Core.Util.AsyncExtensions.<>c__DisplayClass1`1.<CreateCallback>b__0(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at ImageProcessor.Web.Plugins.AzureBlobCache.AzureBlobCache.<IsNewOrUpdatedAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at ImageProcessor.Web.HttpModules.ImageProcessingModule.<ProcessImageAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar)
   at System.Web.HttpApplication.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar)

person Gabriel Robert    schedule 05.10.2016    source источник
comment
Ответ состоял в том, чтобы установить часы на сервере в UTC. stackoverflow.com/questions/22828279 /   -  person Gabriel Robert    schedule 24.10.2016


Ответы (1)


Я не уверен, что сказать здесь. Почти все используется так, как я бы не ожидал и не рекомендовал.

Если вы используете Umbraco в Azure, вы должны использовать следующий подключаемый модуль для своего мультимедиа.

https://github.com/JimBobSquarePants/UmbracoFileSystemProviders.Azure

Используемый вами FileSystemProvider устарел примерно полтора года назад. На самом деле рекомендуется использовать упомянутый выше плагин на своей домашней странице.

НОВЫЙ пакет UmbracoFileSystemProviders.Azure доступен онлайн! см.: https://our.umbraco.org/projects/collaboration/umbracofilesystemprovidersazure/

Я рекомендую его вместо этого, особенно если вы используете Umbraco 7.3 или выше. Это решает множество проблем, которые в противном случае возникали бы у вас в бэк-офисе.

https://our.umbraco.org/projects/backoffice-extensions/azure-blob-storage-provider

Причина этого в том, что у исходного провайдера были недостатки, которые нельзя было исправить без полной перезаписи.

  1. Медиа были сохранены в базе данных с использованием абсолютного URL-адреса. Это означало, что один и тот же носитель нельзя было использовать в нескольких средах.
  2. Медиа загружались и отображались необработанными в бэк-офисе. Это привело к ненужной загрузке 100 МБ данных, что снизило производительность на больших сайтах.

Вам нужно будет заменить свои ссылки на медиа, прежде чем начать работу в своей базе данных, чтобы удалить домен из сохраненного URL-адреса. Я лично рекомендовал бы восстановить ваш раздел СМИ с нуля.

На странице GitHub есть подробные инструкции, но я также перечислю их здесь ниже.

Первый. Удалите старый плагин, обновите все библиотеки ImageProcessor до последних версий и установите рекомендуемый плагин FileSystemProvider.

Затем обновите ~/Config/FileSystemProviders.config, заменив поставщика по умолчанию следующим:

<?xml version="1.0"?>
<FileSystemProviders>
  <Provider alias="media" type="Our.Umbraco.FileSystemProviders.Azure.AzureBlobFileSystem, Our.Umbraco.FileSystemProviders.Azure">
    <Parameters>
      <add key="containerName" value="media" />
      <add key="rootUrl" value="http://[myAccountName].blob.core.windows.net/" />
      <add key="connectionString" value="DefaultEndpointsProtocol=https;AccountName=[myAccountName];AccountKey=[myAccountKey]"/>
      <!--
        Optional configuration value determining the maximum number of days to cache items in the browser.
        Defaults to 365 days.
      -->
      <add key="maxDays" value="365" />
    </Parameters>
  </Provider>
</FileSystemProviders>

Теперь вам нужно настроить CloudImageService для захвата всех запросов, начинающихся с /media/.

<?xml version="1.0"?>
<security>
  <services>
    <service name="LocalFileImageService" type="ImageProcessor.Web.Services.LocalFileImageService, ImageProcessor.Web"/>
    <service prefix="media/" name="CloudImageService" type="ImageProcessor.Web.Services.CloudImageService, ImageProcessor.Web">
      <settings>
        <setting key="Container" value="media"/>
        <setting key="MaxBytes" value="8194304"/>
        <setting key="Timeout" value="30000"/>
        <setting key="Host" value="http://[myAccountName].blob.core.windows.net/media"/>
      </settings>
    </service>
  </services>  

Ensure your Cache config is set up properly.

<caching currentCache="AzureBlobCache">
  <caches>
    <!-- Disk cache configuration removed for brevity -->
    <cache name="AzureBlobCache" type="ImageProcessor.Web.Plugins.AzureBlobCache.AzureBlobCache, ImageProcessor.Web.Plugins.AzureBlobCache" maxDays="365">
      <settings>
        <!-- The Account, Container and CDN details -->
        <setting key="CachedStorageAccount" value="DefaultEndpointsProtocol=https;AccountName=[CacheAccountName];AccountKey=[CacheAccountKey]"/>
        <setting key="CachedBlobContainer" value="cache"/>
        <!-- Whether to add the container name to the CDN url. Newer Azure formats require false. -->
        <setting key="UseCachedContainerInUrl" value="true"/>
        <!-- Full CDN root url e.g http://123456.vo.msecnd.net/ -->
        <setting key="CachedCDNRoot" value="[CdnRootUrl]"/>
        <!-- Optional setting for a timeout limit in milliseconds when attempting to communicate with the CDN url. -->
        <setting key="CachedCDNTimeout" value="1000"/>
        <!-- 
            Optional settings for better identifcation of source images if stored in 
            Azure blob storage.
         -->
        <setting key="SourceStorageAccount" value=""/>
        <setting key="SourceBlobContainer" value=""/>
        <!-- 
            Optional settings facilitate streaming of the blob resource directly instead of a redirect. This is beneficial
            for CDN purposes but caution should be taken if not used with a CDN as it will add quite a bit of overhead 
            to the site. 
         -->
        <setting key="StreamCachedImage" value="false"/>
      </settings>
    </cache>
  </caches>
</caching>

Запросы изображений теперь должны создаваться с использованием только корневого относительного пути /media/, который встроенный поставщик виртуального пути будет перехватывать и обрабатывать соответствующим образом.

e.g /media/1046/car-small.jpg?width=500&height=500&mode=boxpad&bgcolor=hotpink

person James South    schedule 06.10.2016
comment
Считаете ли вы, что исчезновение изображений [conceptjp.com] — вопрос времени? - person Gabriel Robert; 06.10.2016
comment
Боюсь, я не понимаю, о чем вы спрашиваете. - person James South; 06.10.2016
comment
@JamesSouth - я полагаю, он спрашивает, может ли он пропустить вторую половину исправления, которое вы ему предоставили, и просто подождать, пока люди обновят достаточно изображений, чтобы в базе данных не осталось абсолютных URL-адресов. Звучит так, как будто здесь срезано много углов :\ - person Peter Dolkens; 06.10.2016
comment
@JamesSouth Решение состояло в том, чтобы установить часы на сервере в UTC. stackoverflow.com/questions/22828279 / - person Gabriel Robert; 24.10.2016
comment
@GabrielRobert Но это не так .. Я подробно объяснил, почему вы неправильно используете программное обеспечение. Нет смысла спрашивать, если ты не собираешься слушать. - person James South; 25.10.2016
comment
@JamesSouth Ваши рекомендации будут запущены в работу очень скоро [на самом деле они онлайн для сред разработки], но это не решило мою первоначальную проблему [403 везде]. Спасибо за помощь. - person Gabriel Robert; 25.10.2016
comment
Спасибо @GabrielRobert - person James South; 26.10.2016