ПП
А я не готов доверяться чужому решению в авторизации)
А работодатель не готов брать разработчика, который вместо выполнения задачи, будет свои колеса пилить)
Size: a a a
2019 October 04
ПП
Хранить в сервисе :) а куки чем плохо?)
В смысле в сервисе? Всё ещё не понял. 1001 и статья, если коротко, то куки беком юзаются, бэд практис их юзать с фронта
🧤K
А работодатель не готов брать разработчика, который вместо выполнения задачи, будет свои колеса пилить)
Если задача подразумевает написание норм авторизации то всегда у заказчика есть свои сервисы. И к ним лучше писать свой код
ПП
Иначе этот токен гоняться будет каждый раз на бэк и обратно, что тупо
ПП
Ты его по факту два раза будешь передавать
🧤K
В смысле в сервисе? Всё ещё не понял. 1001 и статья, если коротко, то куки беком юзаются, бэд практис их юзать с фронта
Ну пришел токен, сохранил в сервисе и работаешь. Закрыл страницу - потерял токен
ПП
Ну пришел токен, сохранил в сервисе и работаешь. Закрыл страницу - потерял токен
Эмм... Мне стоит объяснять, что это не юзабельно в реалиях нынешнего времени?
🧤K
Я может плохо объяснил. Если есть задача сохранять логгд после переоткрытии страницы - надо хранить в кукисы
ПП
+ к тому же, на куках всего 4кб. Не хочу я их тратить на строку
🧤K
Либо втихую спрашивать через ифрейм
ПП
Либо втихую спрашивать через ифрейм
Это костыли уже
🧤K
Это костыли уже
Нет.
🧤K
Костыли это хранить в локалсторедже))
ПП
Это бест практис
ПП
Я бы ещё понял, если бы речь шла за то, что фронт и бэк на одном серваке, но ангуляр предполагает декомпозирование фронта и бэка
ПП
А тобишь, ты все равно слать будешь в хэдерах
ПП
Browser local storage (or session storage) is not a secure place to store sensitive information. Any data stored there:
Can be accessed through JavaScript.
May be vulnerable to cross-site scripting.
Can be accessed through JavaScript.
May be vulnerable to cross-site scripting.