Комментарии 7
Ага только не во всех браузерах SameSite=None; работает, так же как в новом Chrome. Так что нужен еще фильтр по UA. Потом, кто придумал, что там всегда должно быть Secure. Это вообще не понятно. Если я отдал куки по HTTP, то хочу по HTTP и получить. А вот разработчики Chrome придумали, что так нельзя. Привет, тепер у тебя куча лишнего геморроя с HTTPS для того чтобы запустить и протестить что то локально. Ясно что можно выключить в настройках браузера… Но это пока.
Кажется. Случаи разные бывают. Например, если в проде сервер работает через реверс прокси, а теперь только для отладки чего-то мне это надо локально подымать. И объяснять 100 разработчикам, как это делать. Сделаем конечно, но геморрой реально лишний. Потом этот корневой сертификат, надо где-то хранить, но так чтобы он потом не попал случайно в прод, и одновременно должен быть доступен всем для установки в браузер. А желательно чтоб он там был на девелоперских браузерах сразу. В общем несколько новых бизнес процессов на ровном месте.
не во всех браузерах SameSite=None; работает, так же как в новом Chrome
Вот такой информации у меня нет. В старых браузерах SameSite не поддерживается совсем, но ведь это не значит что они не смогут использовать ресурсы, завязанные на куки. Наоборот, они будут отправлять куки всем.
Или Вы о чём-то другом?
Ну старые версии Chrome ладно оно везде обновляется, но мобильные WebView — привет от пользователей, которые имеют не самые свежие телефоны. И не только телефоны. У нас отвалились мобильные терминалы на Android у клиентов. Конечно в тестах. В проде пока вырубили SameSite=None;, сделаем настройку, чтоб включать только там где надо и ничего не поломается. Привет еще одна настройка за которой надо следить.
SameSite=None, не знал этого. Вечером добавлю в статью.
SameSite=Lax по умолчанию — уже в Chrome 80 stable (правда, пока не у всех)