Почему Salesforce перестал работать после обновления Microsoft Edge и что делать

Что произошло

На прошлой неделе Microsoft выпустила стабильную версию Edge 86. В ней по умолчанию изменено поведение SameSite для cookie: раньше часто применялось SameSite=None; Secure, теперь — SameSite=Lax по умолчанию. Это влияет на сценарии, где веб‑приложение ожидает передачи cookie при переходах между сайтами или при загрузке в iFrame/Visualforce.

Пользователи стали жаловаться, что при клике по ссылке открывается пустая или некорректно отрисованная Visualforce‑страница и что «вид приложения не поддерживается». Сообщения указывают, что неожиданно перестали работать кастомные интеграции и порталы, которые использовали HTTP или не устанавливали явным образом флаги cookie.

Важно: изменение применимо ко всем изданиям Lightning Experience и Salesforce Classic, согласно уведомлениям Salesforce.

Как это влияет на пользователей Salesforce

Коротко:

• Cookies с настройкой по умолчанию теперь не передаются при cross-site запросах.
• Небезопасные HTTP-сайты блокируются для передачи cookie.
• Кастомные интеграции и порталы, зависящие от cookie для сессий или авторизации, перестают работать.

Техническая деталь: заголовок Set-Cookie должен явно содержать SameSite=None; Secure, если cookie требуется передавать в cross-site контексте и доступ по HTTPS. Пример корректной установки cookie:

Set-Cookie: mysession=abc123; SameSite=None; Secure; Path=/; HttpOnly

Что можно сделать прямо сейчас

Ниже — последовательность действий от менее рискованных к более техническим.

1. Проверьте связь: HTTP или HTTPS

   • В Setup → Quick Find введите Session Settings, затем откройте Session Settings и проверьте, не использует ли ваша организация небезопасные коннекты.
   • В Setup → Quick Find введите Sites, выберите сайт и убедитесь, что отмечен флаг Require Secure Connections (HTTPS).

2. Попросите разработчиков явно установить SameSite=None; Secure

   • Если сторонние интеграции используют cookie для сессий, разработчики должны явно выставить SameSite=None; Secure. Это позволит cookie передаваться в cross-site сценариях, но требует HTTPS.

3. Переведите ресурсы на HTTPS

   • Если в вашей архитектуре есть HTTP‑порталы или сайты, переключение их на HTTPS — самое безопасное и рекомендуемое решение.

4. Тестируйте в Sandbox

   • Прогоните изменения в песочнице (sandbox) перед деплоем в продакшн.

5. Временная альтернатива — другой браузер

   • Для быстрой работы можно временно использовать другой браузер. Например, Opera часто остаётся совместимой и содержит встроенные функции (блокировщик рекламы, VPN и т. п.). Это обходной путь, но не решает проблему безопасности.

Важно: сброс настроек Edge или очистка кеша/куки не исправит проблему, если причина — SameSite‑политика и незащищённый HTTP.

Рекомендации для разработчиков и администраторов

• Всегда устанавливайте cookie с флагами: SameSite=None; Secure; HttpOnly, когда требуется cross-site доступ.
• Минимизируйте использование cookie для межсайтовой аутентификации; используйте OAuth 2.0 / явные токены с безопасными заголовками.
• Переведите все публичные и интеграционные точки на HTTPS с корректными сертификатами.
• Добавьте автоматические тесты, имитирующие поведение браузеров с разными SameSite по умолчанию.

Короткая проверочная методика (минимум для проверки):

1. Откройте страницу, вызывающую Visualforce/портал в контексте cross-site.
2. Откройте DevTools → Network и посмотрите, отправляются ли cookie в запросах.
3. Проверьте заголовки Set-Cookie у ответов от сервера.

Контрольный список для миграции

• Проанализировать какие интеграции используют cookie.
• [ ] Внедрить явную установку SameSite=None; Secure там, где это требуется.
• Перевести все сайты и порталы на HTTPS.
• Протестировать в sandbox и в браузерах (Edge, Chrome, Firefox, Opera).
• Обновить документацию и уведомить пользователей.

Когда это решение не сработает (примеры и ограничения)

• Если интеграция работает через протоколы, которые не используют cookie (например, чистый token‑based API), изменение SameSite не поможет — требуется другой подход.
• Если у вас нет контроля над сторонним сервисом, который устанавливает cookie, нужно согласовать обновления с поставщиком.
• В старых мобильных браузерах или в кастомных WebView поведение может отличаться.

Быстрые тесты (acceptance)

• Откройте вход в Salesforce через интеграционный портал. После входа — сессия должна сохраняться и возможность навигации по Visualforce — оставаться корректной.
• В Network убедитесь, что cookie присутствует в запросах к домену Salesforce и имеет SameSite=None; Secure если требуется cross-site передача.
• Проверка в Edge 86 и в другом браузере должна дать одинаковое поведение после правок.

Альтернативные подходы

• Перейти на token‑based авторизацию (JWT, OAuth 2.0) для межсайтовых сценариев.
• Использовать прокси на стороне сервера, чтобы избегать cross-site cookie и передавать нужные данные через защищённые заголовки.

Резюме

Обновление Edge 86 изменило поведение SameSite по умолчанию, что привело к проблемам с передачей cookie в cross-site сценариях и вызвало сбои в некоторых кастомных решениях Salesforce. Решения: явно выставлять SameSite=None; Secure, перевести сайты на HTTPS и протестировать изменения в sandbox. Временная альтернатива — использование другого браузера, но это не заменяет исправление серверной конфигурации.

Важно: планируйте изменение архитектуры (переход на HTTPS и token‑based авторизацию) как долгосрочное решение безопасности и совместимости.

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

Мы также публиковали материал о проблемах Salesforce в Chrome — если у вас есть похожие ошибки, стоит сравнить поведение в разных браузерах.