2017-02-16 13 views
0

Мы используем функцию HTML5 Application Cache:HTTP Strict Transport Security и HTML5 приложений Cache

<html manifest=".appcache"> 
    ... 
</html> 

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

После загрузки приложения он будет выполнять запросы AJAX для загрузки динамического содержимого, а браузер проверяет, устарел ли кэш приложения, и, возможно, загрузить новую версию приложения в фоновом режиме.

Многие из наших пользователей получают доступ к этому приложению по небезопасным соединениям (HTTP, а не HTTPS).

Мы внедряем HTTP Strict Transport Security (HSTS) на серверах, на которых размещено приложение.

Реализация HSTS означает, что наши серверы будут обрабатывать запросы, как это:

  • Если запрос является небезопасным (HTTP только), то сервер будет реагировать со статусом HTTP 301 и заголовок Location, который перенаправляет на запросил URI, но изменил схему на https.

  • В противном случае; если запрос защищен (HTTPS), сервер будет обрабатывать его как обычно, но украсить ответ заголовком Strict-Transport-Security.

Таким образом, когда новый пользователь откроет наше приложение через HTTP, они будут перенаправлены на HTTPS вместо, а затем манифест кэша приложения устанавливается с помощью безопасного места. Отлично.

Однако возвращающийся пользователь (через HTTP) НЕ будет перенаправлен в безопасное место (поскольку у них уже есть кешированная версия в небезопасном местоположении). Кэш приложения не загружается (поскольку это перенаправление). Поэтому возвращающиеся пользователи застревают с версией приложения, которую они кэшировали, и они застревают с использованием HTTP, который больше не разрешен. Это очень плохо.

Нам нужно придумать способ перехода пользователей HTTP на версию HTTPS. Как лучше всего это сделать?

Как я вижу это есть две проблемы:

  1. Браузер не может принести манифест приложения (потому что это перенаправление). Поэтому невозможно обновить приложение до новой версии.

    Возможно, мы преодолели эту проблему, настроив наши серверы, чтобы можно было обслуживать /.appcache через простой HTTP.

  2. Даже если мы делаем это, приложение будет по-прежнему доступны на месте HTTP (так что то, что кэшируется манифеста)

    Чтобы обойти это, мы могли бы реализовать какой-то Javascript логика, которая изменяет схема от document.location.href до HTTPS.

    Мне не нравится этот подход, но это единственный, который у нас есть на данный момент.

ответ

0

Мы остановились на следующем решении этой проблемы:

Когда сервер получает небезопасный запрос, чтобы получить кэш манифест приложения (/.appcache в нашем случае), то 404 возвращается ответ вместо нормальный HTTPS-переадресация (301).

Получение 404 вызывает кэшированные манифест быть устаревшим, и поэтому браузер будет пытаться перезагрузить приложение на следующем обновлении, которое заставит его принести index.html и быть перенаправлены на безопасное место.