#http #ssl #caching #dns
#http #ssl #кэширование #dns
Вопрос:
Итак, я изменил настройки DNS для своего сайта пару недель назад, и с тех пор он отображается как «Безопасный» для одного из моих аккаунтов Google, но «Небезопасный» для другого аккаунта Google.
Многие из моих друзей, которые посещали сайт раньше, видят это же уведомление «Небезопасно», и оно рекомендует пользователю не вводить данные кредитной карты. Но любой, кто посещает сайт в первый раз, видит «Безопасно». Очевидно, что это выглядит не очень хорошо.
Сначала я подумал, что это просто проблема с распространением, но после 2 недель той же проблемы стало очевидно, что это должно быть как-то связано с кэшем, поскольку он отображается только для людей, которые были на сайте раньше. Я действительно хотел бы понять, что здесь происходит и как я могу это исправить.
Комментарии:
1. Неясно, что вы имеете в виду, когда сайт отображается по-разному для разных учетных записей Google . Какое отношение к учетной записи имеет отображение сайта? Кроме того, проблема не может быть воспроизведена на основе текущего объема информации — по крайней мере, нужно знать имя домена. Если вы не хотите его публиковать, проанализируйте свой сайт с помощью SSLLabs и исправьте свой сайт, пока не получите хотя бы рейтинг A по всем возможным IP-адресам, которые могут быть у вашего сайта. Тогда ваша проблема, возможно, была решена при выполнении этого также.
2. @SteffenUllrich Спасибо за информацию и ссылку на SSLLabs. Он получил все пятерки. «Какое отношение имеет отображение сайта к учетной записи?» Я думаю, на самом деле это суть моего вопроса. Я просматривал сайт с одной из своих учетных записей Google, когда он был небезопасен. И когда я просматриваю сайт с этой учетной записью, он по-прежнему отображается как небезопасный. Однако, если я рассматриваю его как свою другую учетную запись Google, он показывает «Безопасно». И почти у всех, кто просматривал сайт до того, как он был защищен, возникает такая же проблема. Но у всех новых пользователей, которые впервые просмотрели его после того, как он был защищен, этой проблемы нет. Имеет ли это смысл?
3. Нет, это не имеет смысла. Вы можете просматривать сайт с помощью браузера, но вы не можете просматривать сайт «с этой учетной записью» . Вы имеете в виду, что отображение сайта меняется в зависимости от того, с какой учетной записью вы вошли в Google при использовании браузера? Я думаю, вам действительно нужно предоставить другим возможность воспроизвести вашу проблему, т. Е. предоставить фактический URL, где возникает проблема.
4. @SteffenUllrich imgur.com/a/E6xMSWT вот сравнение между двумя разными учетными записями Google в Chrome. Снято несколько минут назад.
Ответ №1:
На самом деле этот вопрос не имеет никакого отношения к разным учетным записям Google, а скорее к разным рабочим средам, которые могут быть связаны с разными учетными записями, но на самом деле в этом нет необходимости. Я предполагаю, что вы меняли конфигурацию своего веб-сайта: там, где у вас когда-то было перенаправление 301 с http:// на https:// , вы удалили его позже.
В среде, в которой вы посещали сайт в то время, когда перенаправление было активным, он получил перенаправление 301 и, таким образом, переместился с http:// на https:// . Поскольку 301 — это постоянное перенаправление, оно кэширует эту информацию, то есть при каждом вводе http://your-domain она будет напрямую перенаправляться на https://your-domain без предварительной проверки на сервере.
В других средах браузер не знает, что когда-то было перенаправление 301, поскольку он никогда его не видел и поскольку его больше нет. Таким образом, браузер останется на http:// сайте, поскольку это то, что браузер делает по умолчанию. Если вы очистите все кэши в среде, в которой вы получаете https:// , он больше не должен помнить кэшированный 301 и вести себя аналогично другим средам, т. Е. оставаться в http:// , а не автоматически переходить в https:// .
Обратите внимание, что вместо перенаправления 301 вы, возможно, также установили заголовок HSTS и удалили его позже. Это имело бы тот же эффект.
Чтобы устранить проблему и заставить всех посетителей переходить на защищенную https:// версию вашего сайта, вам необходимо снова установить 301 перенаправление и / или заголовок HSTS — и на этот раз сохранить его установленным.
Комментарии:
1. Интересно. Я не думаю, что у меня есть какие-либо 301 перенаправления, но я мог бы. Мой DNS-провайдер указывает непосредственно на пользовательское доменное имя heroku с записями CNAME. Будет ли это проблемой, поскольку он не указывает непосредственно на IP? Это приложение Rails, которое использует SSL на уровне приложения. Возможно, это работает как перенаправление? Я несколько раз пытался очистить свой кэш, но безрезультатно. Как я могу исправить это для предыдущих пользователей, которые испытывают то же самое?
2. «Это приложение Rails, которое использует SSL на уровне приложения. Возможно, это работает как перенаправление? » — это может быть. Такое перенаправление или настройка заголовка HSTS также могут быть выполнены из приложения. Но проблема в том, что вопреки вашему утверждению в настоящее время ничто не поддерживает SSL. Если вы предполагаете, что это было сделано приложением rails, вероятно, это сработало в какой-то момент (и, следовательно, было кэшировано в некоторых средах), но в вашем приложении может быть недавно введена ошибка, которая приводит к тому, что SSL больше не используется.
3. «Я несколько раз пытался очистить свой кэш безрезультатно». — неясно, что именно вы здесь делали и в какой среде. Очистка кэша не поможет принудительно использовать SSL, она поможет больше не принудительно использовать SSL, только если все сделано правильно и в нужной среде.