Спасибо! Можно попробовать задачу реализовать через via самого Notification, прокидывая туда нужное условие. Мне казалось, что должно быть более изящное решение.
Николай Смирнов, В Ларавеле Eloquent модель представляет одну таблицу, а у меня задача сделать модель, которая содержит данные из нескольких таблиц и еще некоторые данные, которые вычисляются в сыром запросе. В текущей реализации я использую локальный скоуп во всех запросах модели(модель относится к одной таблице, а остальные данные из других таблиц я получаю уже в скоупе). Но было бы изящнее и безопаснее, если бы я мог использовать один глобальный скоуп для всех запросов, вместо локального скоупа на каждый запрос.
Ramm, У меня в обоих случаях одинаковый код (апдейт модели) $order->save();
Обсервер должен срабатывать при изменении модели. Для теста сделал консольную команду для другой модели(на которой есть Observer) тоже самое. Через веб работает, через консоль нет (абсолютно идентичный код)
Дима Турков, Так-то у Яндекса нет секций, в которых могли бы размещаться h1. Не считаю, что Яндекс следует брать за эталон при сравннении с обычным сайтом. И вообще мой вопрос относится не к области спецификации, а к области SEO.
Юрий Лядов, А количество отправляемых писем может как-то навредить репутации и занести в спам-листы домен?
Для моего случая этот вопрос не уместный, но тут у меня уже проснулось професссиональное любопытство)
Dmitry Bay, Ответ норм. Но решение я нашел раньше чем был комментраий со ссылкой. longclaps подкинул в какую сторону копать, и я эту либу прикрутил. Алгоритм тот же. Но тогда в за*бе был не ставил ответ на этот вопрос. Сейчас наткнулся, вспомнил.
Alexander Leonchik, Интересная реализация. Только не ясен один момент. Если злоумышленник украл куку и начал пользоваться токеном, то и он(злоумышленник) и реальный пользователь смогут спокойно пользоваться этим токеном (если каждый запрос только увеличивает время жизни токена). Пока пользователь не заметит, что у него какая-то дичь твориться. А может и не заметит.
Цитата из гиста:
мы записываем в Redis индефикаторы refresh токенов которые заблокировал пользователь
Во-первых, если злоумышленник получил refreshToken он будет им пользоваться пока не зайдет реальный пользователь с данным токеном. Я в своем вопросе не расписывал всю схему но в случае, если refreshToken провалидировался (подпись валидна) и такой записи нет(перезаписался при протухании accessTokena), то находим все токены данного пользователя и удаляем.
Во-вторых прочитайте внимательней там описан случай использования залогинивание с нескольких устройств.
В-третьих логин с только с одного устройства не бреда, а вполне актуалальный кейс. Работает в платных сервисах. Чтобы с одной учётки одновременно не пользовались продуктом много пользователей.
Зачем мне городить oauth? Проблема в том, я нем могу использовать сессии и куки в запросах от мобильного приложения и в запросах от реакта.