Друзья, нормальный ли это сценарий, когда бэк отдает SPA-фронту (браузер) токен авторизации в явном виде (не в HTTP-only куке)? Кто так делает, как обезопаситься от того, что сторонний JS-код, загруженный из CDN, или скомпиленный из npm, или в расширении для браузера, сможет прочитать и передать такой токен на сторону?

Друзья, нормальный ли это сценарий, когда бэк отдает SPA-фронту (браузер) токен авторизации в явном виде (не в HTTP-only куке)? Кто так делает, как обезопаситься от того, что сторонний JS-код, загруженный из CDN, или скомпиленный из npm, или в расширении для браузера, сможет прочитать и передать такой токен на сторону?

А в Authorization header?

А в Authorization header?

Ты имеешь ввиду авторизовывать потом запросы от фронта к бэку таким способом? Это ок. Токен должен как-то храниться на фронте, чтобы его можно было засунуть в конфиги траспорта AJAX. И оттуда, где он хранится, его можно прочитать.

А чтобы при закрытии вкладки авторизация не слетала, хранить его надо все равно в куках или в local storage

ну, если логично судить, то без http-only кук ты не скроешь токен. Они для того и сделаны, чтобы джаваскрипт не смог прочесть их.

ну, если логично судить, то без http-only кук ты не скроешь токен. Они для того и сделаны, чтобы джаваскрипт не смог прочесть их.

Привет, токен на фронте ты никак не защитишь, тут надо подходить со другой стороны - подключаем и используем только доверенные/проверенные пакеты, потому что на самом деле кража токена это самое меньшее что может сделать вредоносный скрипт

Привет, токен на фронте ты никак не защитишь, тут надо подходить со другой стороны - подключаем и используем только доверенные/проверенные пакеты, потому что на самом деле кража токена это самое меньшее что может сделать вредоносный скрипт

Кража токена = возможный доступ к скрытым данным

Привет, токен на фронте ты никак не защитишь, тут надо подходить со другой стороны - подключаем и используем только доверенные/проверенные пакеты, потому что на самом деле кража токена это самое меньшее что может сделать вредоносный скрипт

По поводу пакетов - согласен, тут надо быт ьвнимательнее

ну, если логично судить, то без http-only кук ты не скроешь токен. Они для того и сделаны, чтобы джаваскрипт не смог прочесть их.

Спасибо, тогда разовью мысль о моей проблеме, используя HTTP-only cookie. В приложении есть быстрый переход по контекстам авторизации. Почти как в гугле: тыкаешь на иконку в правом верхнем углу и переавторизовываешься за другое лицо. Возникла проблема: пользователь может начать заказывать продукт за одно лицо, в соседней вкладке переавторизоваться и продолжить заказывать продукт уже не за того, для кого форма была предназначена. 1 решение. Если бы не HTTP-only cookie, то можно было бы сложить токен авторизации в window, и пока вкладка открыта, производить все действия на сайте от лица единственного человека, за которого страница была открыта. 2 решение. Придумал подписывать формы токеном на основе авторизации. Как CSRF, только при каждой смене контекста такой токен будет перегенерироваться. Может быть у кого-то были подобные кейсы и могут поделиться опытом?

Кража токена = возможный доступ к скрытым данным

Я понимаю, я к тому что если уж скрипт вредоносный то кражой токена там может и не обойтись, подмена информации на странице, отправка данных формы не туда и т.д

ну, если логично судить, то без http-only кук ты не скроешь токен. Они для того и сделаны, чтобы джаваскрипт не смог прочесть их.

пока оптимальный вариант который используется - часть токена в куках часть в заголовках. Тогда как бы и от CSRF защищены и от XSS

Спасибо, тогда разовью мысль о моей проблеме, используя HTTP-only cookie. В приложении есть быстрый переход по контекстам авторизации. Почти как в гугле: тыкаешь на иконку в правом верхнем углу и переавторизовываешься за другое лицо. Возникла проблема: пользователь может начать заказывать продукт за одно лицо, в соседней вкладке переавторизоваться и продолжить заказывать продукт уже не за того, для кого форма была предназначена. 1 решение. Если бы не HTTP-only cookie, то можно было бы сложить токен авторизации в window, и пока вкладка открыта, производить все действия на сайте от лица единственного человека, за которого страница была открыта. 2 решение. Придумал подписывать формы токеном на основе авторизации. Как CSRF, только при каждой смене контекста такой токен будет перегенерироваться. Может быть у кого-то были подобные кейсы и могут поделиться опытом?

если ты залогинился в другой вкладке в первой слетает сессия и там та же карзина что и у второго. Хочет работать из двух режимов - пусть в инкогнито запускает

пока оптимальный вариант который используется - часть токена в куках часть в заголовках. Тогда как бы и от CSRF защищены и от XSS

А можно поинтересоваться - это как? Может чтиво есть? Мы как раз на jwt переходим, и хотелось бы максимально обесопаситься

Обесопаситься это пять)

А можно поинтересоваться - это как? Может чтиво есть? Мы как раз на jwt переходим, и хотелось бы максимально обесопаситься

ну вот в jwt - подпись в куки, токен в заголовки

ну вот в jwt - подпись в куки, токен в заголовки

А в заголовке мы держим только header и payload?

А в заголовке мы держим только header и payload?

да. Но вообще - опять же, можно просто всегда токен хранить в куках и просто проверять Origin/Referer заголовки

что бы не допускать что кто-то ходит в нашу апишку с токеном с неизвестных нам хостов

да. Но вообще - опять же, можно просто всегда токен хранить в куках и просто проверять Origin/Referer заголовки

Я так понимаю, это если есть возможность обойтись куками. А если нету, то тогда разделить токен на части. Спасибо, узнал что-то новенькое)

если ты залогинился в другой вкладке в первой слетает сессия и там та же карзина что и у второго. Хочет работать из двух режимов - пусть в инкогнито запускает

А как "первая" узнает, что сессия слетела, если кука с токеном http-only?

А как "первая" узнает, что сессия слетела, если кука с токеном http-only?

пойдет делать запросы на изменение чужой карзины и узнает

то есть форму изменения корзины тоже чем-то подписывать надо

это настолько редкий кейс что думать о юзер френдли тут смысла нет

то есть форму изменения корзины тоже чем-то подписывать надо

она за пользователем конкретным должна быть закреплена в любом случае

резюмируя, любая форма должна иметь некоторый идентификатор контекста под которым она заполнялась, и который должен валидироваться на бэк-энде?

какая к черту форма?

а ну.... или у тебя карзины на сервере не существует?

какая к черту форма?

форма = любой POST-запрос.

а ну.... или у тебя карзины на сервере не существует?

вообще корзин не существует. Точечный заказ продуктов из форм

хватит мыслить формами

хватит мыслить формами

ок, я только для понятности

вообще корзин не существует. Точечный заказ продуктов из форм

просто обычно "добавить в корзину" это посложнее операция нежели просто добавить айдишку и колличество. Товар надо зарезервировать что бы если у тебя есть 10 яблок нельзя было словить заказ на 20 яблок от двух пользователей

вообще корзин не существует. Точечный заказ продуктов из форм

Интернет магазин оч маленький я так понимаю?

Здесь другой кейс. Это не интернет-магазин. Это страховая, которая продает страховые продукты с ооочень многими комбинациями полей, личными данными, настройками продукта и т.д. и т.п. Корзинами здесь мыслить не приходится

Речь даже не о продуктах. Я не хочу позволять юзеру делать любой POST-экшен не за того человека, за которого заполнение формы начиналось

Речь даже не о продуктах. Я не хочу позволять юзеру делать любой POST-экшен не за того человека, за которого заполнение формы начиналось

у тебя оч странный и специфичный кейс, хз короч

у тебя оч странный и специфичный кейс, хз короч

Кейс - да, проблему пытаюсь описать максимально абстрактно. В итоге - вы не заморачиваетесь насчет этой проблемы или подписываете POST-запросы идентификатором сессии/пользователя?

Кейс - да, проблему пытаюсь описать максимально абстрактно. В итоге - вы не заморачиваетесь насчет этой проблемы или подписываете POST-запросы идентификатором сессии/пользователя?

не заморачиваемся ибо ничего плохого сделать он не может

Ребята объясните пожалуйста. Абстрактный класс, какие у него плюсы и минусы? Я пятый раз читаю документацию,делаю маленькие примерчики, и все равно не понимаю. Ведь там сказано,что абстрактный класс обязан иметь строгую типизацию,к примеру приватный в абстракте не может стать публичным. Так объясните мне

Но на деле все наоборот,написав публичный метод в дочернем классе того же приватного метода в абстрактном классе,он выдает данные. Хотя обязана быть ошибка

Но на деле все наоборот,написав публичный метод в дочернем классе того же приватного метода в абстрактном классе,он выдает данные. Хотя обязана быть ошибка

Суть приватного метода в том, что он доступе только текущему классу, в котором объявлен. Если ты создашь такое же метод в дочернем классе, то это уже "другой скоуп" так сказать

Ребята объясните пожалуйста. Абстрактный класс, какие у него плюсы и минусы? Я пятый раз читаю документацию,делаю маленькие примерчики, и все равно не понимаю. Ведь там сказано,что абстрактный класс обязан иметь строгую типизацию,к примеру приватный в абстракте не может стать публичным. Так объясните мне

Абстрактные классы оч редко используются на практике. По факту они нужны, когда у тебя есть интерфейс, но часть функционала в описываемых реализациях обязательно повторяется - ты ее выносишь в абстракцию

Абстрактные классы оч редко используются на практике. По факту они нужны, когда у тебя есть интерфейс, но часть функционала в описываемых реализациях обязательно повторяется - ты ее выносишь в абстракцию

И то не всегда. Я выношу такое если много реализаций есть, и немножко убрать дублирование какой-то простой логики (в основном геттеры\сеттеры)

геттеры\сеттеры в абстрактом классе - путь в макдональдс

Абстрактные классы оч редко используются на практике. По факту они нужны, когда у тебя есть интерфейс, но часть функционала в описываемых реализациях обязательно повторяется - ты ее выносишь в абстракцию

если мы про джаву то даже если у тебя есть дефолтная реализация нет смысла городить абстрактный класс - интерфейс может содержать реализацию

если мы про джаву то даже если у тебя есть дефолтная реализация нет смысла городить абстрактный класс - интерфейс может содержать реализацию

ну раз уж мы в пхп чате, то мы не про джаву)

перепутал чаты сорян

ну раз уж мы в пхп чате, то мы не про джаву)

а какая разница)

действительно

джава и пхп - одно и то же

два хороших яызка

у абстрактного класса должен быть приватный стеит, на который нельзя повлиять из наследников. Иначе это всё плохо закончится под благим предлогом "я же убираю копипасту".

у абстрактного класса должен быть приватный стеит, на который нельзя повлиять из наследников. Иначе это всё плохо закончится под благим предлогом "я же убираю копипасту".

Иногда это переходит в слепое наследование принципа dry

а потом трейты и наркотики

у абстрактного класса должен быть приватный стеит, на который нельзя повлиять из наследников. Иначе это всё плохо закончится под благим предлогом "я же убираю копипасту".

Я написал абстрактный приватный метод(ПО ДОКУМЕНТАЦИИ СКАЗАНО),начинаю делать дочернии класс от абстрактного класса,и называю этот же метод публичным,данные выводятся,ошибок нет. В доках сказано: что типизация самая строгая в абстракте.

и анальный секс

Я написал абстрактный приватный метод(ПО ДОКУМЕНТАЦИИ СКАЗАНО),начинаю делать дочернии класс от абстрактного класса,и называю этот же метод публичным,данные выводятся,ошибок нет. В доках сказано: что типизация самая строгая в абстракте.

а как вы понимаете типизацию в этом случае?)

Ребята объясните пожалуйста. Абстрактный класс, какие у него плюсы и минусы? Я пятый раз читаю документацию,делаю маленькие примерчики, и все равно не понимаю. Ведь там сказано,что абстрактный класс обязан иметь строгую типизацию,к примеру приватный в абстракте не может стать публичным. Так объясните мне

в php: плюсы: - может иметь дефолтную реализацию методов минусы: - может иметь protected стэйт - а это всегда огромный минус и прощай досвиданья старушка Лисков - для классов нет множественного наследования а потому сильно ограничивается иерархия тиипов

а как вы понимаете типизацию в этом случае?)

int - int, string = string, приватный и приватный. Если что то другое выводится,ошибка

я абстрактный класс юзаю в основом для классов типа JsonResponse :)

int - int, string = string, приватный и приватный. Если что то другое выводится,ошибка

ну, это немножко разные вещи типизация и тип доступа функций

Так сказано в доках: кроме того, область видимости этих методов должна совпадать (или быть менее строгой)

Я написал абстрактный приватный метод(ПО ДОКУМЕНТАЦИИ СКАЗАНО),начинаю делать дочернии класс от абстрактного класса,и называю этот же метод публичным,данные выводятся,ошибок нет. В доках сказано: что типизация самая строгая в абстракте.

возможность объявить приватный метод который невозможно перегрузить из подтипов (он же приватный, только из контекста этого класса может быть вызван) никакого отношения не имеет к абстрактным или просто классам. Это банальная логика. инстанс класса не может вызвать у себя метод о котором он ничего не знает, следовательно он никак не сможет вызвать публичный метод подтипа.

Так сказано в доках: кроме того, область видимости этих методов должна совпадать (или быть менее строгой)

ну так public/protected - это менее строгий)

ну так public/protected - это менее строгий)

public/protected подразумевает возможность перегрузки. private - нет

ERROR: S client not available

public/protected подразумевает возможность перегрузки. private - нет

Интересненько

ну бля подумай просто, это ж было бы тупо

хотя вполне в духе php но всеравно тупо

Ладно благодарю. Спасибо)

в php: плюсы: - может иметь дефолтную реализацию методов минусы: - может иметь protected стэйт - а это всегда огромный минус и прощай досвиданья старушка Лисков - для классов нет множественного наследования а потому сильно ограничивается иерархия тиипов

а как мы лисков нарушаем? в том плане что подтипы не контролируют свой стейт?

а как мы лисков нарушаем? в том плане что подтипы не контролируют свой стейт?

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

а зная среднестатистических php-ников они 100% проебутся

> инварианты ?

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

ааа, в том плане, что инвариант для одного под-типа может быть норм, а вот для другого - какаха

а в чем плюсы дефолтной реализации

я думал это и есть минус основной

типо что класс называется абстрактным, а в нем конкретика

плюсы что у тебя инстанциировать класс нельзя, но реализация может быть и ее можно использовать в потомках.

ну в моём случае - это способ быстро и легко запрятать инфраструктуру, не усложняя реализации в целом.

ну мол это единственный плюс абстрактных классов. Если тебе это не надо - тебе они вообще не нужны

по сути мы присобачиваем какой то метод к интерфейсу

нет ли тут проблемы проектирования

и не нужно ли этот метод вынести в другой объект

не всегда оправдано

и да - я руководствуюзсь предположением что описание стэйта класса, даже если оно одинаковое никак не может быть дублированием ибо в противном случае зачем тебе делать 2 класса а не один

нет ли тут проблемы проектирования

иногда это удобно. Погугли почему в java добавили реализацию методов у интерфейсов - хороший пример такого кейса

и да - я руководствуюзсь предположением что описание стэйта класса, даже если оно одинаковое никак не может быть дублированием ибо в противном случае зачем тебе делать 2 класса а не один

у меня в проекте копипаст детектор, наверное, тупо повиснет)

у меня в проекте копипаст детектор, наверное, тупо повиснет)

не факт)

сотни практически идентичных структурок)

я про protected стэйт)

а, в хер его. уже нажрался говна

private стэйт в абстрактном классе которым можно рулить только через методы - ну.... это имеет право на жизнь

просто... тогда extends можно заменить на агрегацию/композицию. Простто иногда абстрактный класс удобнее

просто... тогда extends можно заменить на агрегацию/композицию. Простто иногда абстрактный класс удобнее

именно. просто it depends

опять-таки, если есть понимание происходящего. а не просто "копипасту убрать"

К свойствам в абстрактном классе можно добавлять abstract public $name;

JetBrains на такое ругается