Frontend будет не SPA? Старые добрые HTML странички? Вроде речь шла про SPA?
Потому как если SPA, то как планируешь в нем работать с httpOnly cookies?
Фронтенд планирую как SPA на REST-е. Мне сейчас не очевидно почему должны быть проблемы с http-only куками для такой конфигурации. Я представляю ситуацию так (но в ней не был никогда): авторизовываюсь, получаю куку на домент, шлю AJAX запросы на этот же самый домент, кука гоняется вместе с запросами.
Я не представляю где была бы проблема, если бы АПИ и само приложение лежало бы на разных доменах. Авторизацию все равно я бы делал уна домене где лежит API, соответственно кука привязалась бы к этому домену.
Как я понимаю ситуацию - HTTP-only кука - это кука к которой js не имеет доступа. Это единственное ее отличие от не http-only.
Как я понимаю ситуацию - HTTP-only кука - это кука к которой js не имеет доступа. Это единственное ее отличие от не http-only.
Соответственно с AJAX запросом http-only кука ходить не будет, так?
Будет.
Это означает что я не смогу прочитать ее значение из js через document.cookie.
С точки зрения безопасности это значит что, например, злоумышленник, встроив злой js в мой бандл или библиотеку не сможет украсть пользовательскую сессию.
Ага туплю, то наоборот у нас обратный случай был, у нас не было куки, только токен, а надо было как-то понять кто это, при прямом запросе от броузера, не AJAX.
Как в итоге решили? Положили в куку?
У нас аутотентификация через Google Firebase Auth, он нам токен дает. Добавили куку на любом запросе на наш сервер, получилось костыльно. Если запрос от броузера обгоняет запрос на который выдается кука, то облом. У нас картинки приватные в tag image должны вставляться. Выручает, что броузер делает повторный запрос и он проходит. Хотелось бы решить вопрос нормально, но пока не придумали. Кстати, надо глянуть может Firebase Auth куку тоже выдает как вариант.
Посмотрие на вариант сделать авторизацию через ваш сервер. Потом давайте клиенту токен чтобы он мог писать напрямую в firebase.
Такой подход выглядит не шибко простым если подумать над реализацией. Зато на вашем сервере всегда будет знание про авторизованность пользователя.
UPD вот это: https://firebase.google.com/docs/auth/web/custom-auth
То что у себя можно сделать это понятно, проект уже пришел к нам с Firebase Auth. Переделывать auth на свой сервер нам пока не дадут, без особой необходимости. Щас глянули там и куки вроде есть. Надо будет почитать подробнее, при случае.
Это понятное бизнес-решение. Значит пока можно
- проверить нет ли авторизационной куки, если нет, то
- авторизоваться
- поставить авторизационную куку
- перезагрузить страницу
такой порядок будет гарантировать что кука стоит. Масштаб последствий тут не продумывал.
Еще вариант - пустить загрузку всез картинок через “обожди пока авторизуется пользователь”. Типа вместо <img src="private-image.png" /> делаешь <img data-src="private-image.png">, а после авторизации и установки куки пробегаешься по всем картинкам с data-src, и проставляешь уже настоящий src. Минусов - мигание.