Не факт, что там 4ре кнопки, у кого нибудь может быть больше или в будущем планируется добавить. Нормальный у них дизайн, что удивительно для гос. структуры.
Про вторую часть не совсем понятно (Feature toggles). У Вас backend автоматически выключает функциональность на клиенте? Если нет, то тогда не понимаю зачем такие трудности. Вряд ли курьер напрямую будет отправлять запросы в API. Если это из за безопасности, то можно решить на уровне разделения прав доступа.
Если у Вас упрут access, то и упрут refresh и будут безконтрольно выписывать access токены. Если он конечно не в памяти или не в блокноте. В базу я лезу раз в 30 минут (можно чаще, можно реже). Это позволяет контролировать access токены. Пользователь имеет возможность закрыть лавочку по выписыванию токенов. В моем случае не смогут им пользоваться, т.к fingerprint сразу прикроет лавочку (можно делать более детальный fingerprint на клиенте). Refresh токен живет два месяца или пока пользователь сессию не закроет.
P.S. Простите что не по библейским законам живу, зато на клиенте не надо париться по выписыванию токенов.
refresh token нужен чтобы идентифицировать сессию. Убил в базе refresh, новый access не получишь и все access выписанные c этим refresh тоже не работают. refresh живет два месяца, затем пользователь заходит по логину и паролю, текущая удаляется, новый refresh.
Отправил пользователь 5ть запросов параллельно получил 5ть access токенов, если они в запросе не валидны. Все они на клиенте друг друга перезапишут. Далее будет валидный токен. Минус лишь в том что при каждом получении access токена идет запрос в базу. Если вы контролируете клиент, то не проблема. Если сторонняя компания использует api, то ограничиваете ее на сервере (баните большом количестве запросов с невалидным токеном).
Я не вижу причин этого не делать. У меня клиент отправляет только jwt, Нет заморочек с повторными запросами, перевыпусками токенов и т.д. Пользователь зашел в профиль увидел свою активность по сессиям (детальную). Увидел что то не то, дропул лишнее и живет спокойно.
Где вы храните access token и refresh token?
Вот знал что прилетит. А Refresh token у Вас в блокнот записан, его никто не упрет? В моем случае refresh token определяет сессию. Также есть fingerprint клиента (хешь user agent + ip), тоже зашит в jwt. Допустим JWT уперли и начинают просится в гости, fingerprint не совпал сессия удаляется (вместе с refresh token).
Я на клиенте вообще не проверяю, что время токена вышло. Пришел запрос на сервер, если время вышло и refresh token жив, то отправляю в заголовке новый. Клиент смотрит на этот заголовок и если он не пустой, то сохраняет новый токен.
Я редко покупаю через интернет за бугром и меня это мало бы волновало, если бы не одно но. Наши «бедные» интернет магазины, которые еле выживают на рынке, которым нужно помочь, сразу поднимут цены.
И это означает, что создание отдельной версии веб-сайта под мобильные устройства не спасет ситуацию.
Не совсем понял. Я вот не любитель адаптивной верстки. По мне лучше сделать две отдельных версии. Изначально затраты будут выше, но в будущем окупятся. Отдельный мобильный сайт, который визуально не отличается от мобильного приложения IOS, android будет ниже в выдачи адаптивного?
В наследство достался зоопарк cms. Все разные, порядка 8, включая все популярные, кроме drupal. Ни одна из них не удовлетворяла потребностям, я уж не говорю про дырки. Написал болванку на yii2. Под каждый проект создаем ветку и накручиваем до нужной кондиции. Интерфейс пишется для людей, которые выкладывают материал. Если им, что то не удобно делать, то мы оптимизируем процесс. Все довольны, а сколько счастья в глазах =) и ни единого разрыва (пока никто не взломал, тьфу, тьфу).
P.S. Простите что не по библейским законам живу, зато на клиенте не надо париться по выписыванию токенов.
Отправил пользователь 5ть запросов параллельно получил 5ть access токенов, если они в запросе не валидны. Все они на клиенте друг друга перезапишут. Далее будет валидный токен. Минус лишь в том что при каждом получении access токена идет запрос в базу. Если вы контролируете клиент, то не проблема. Если сторонняя компания использует api, то ограничиваете ее на сервере (баните большом количестве запросов с невалидным токеном).
Где вы храните access token и refresh token?
Не совсем понял. Я вот не любитель адаптивной верстки. По мне лучше сделать две отдельных версии. Изначально затраты будут выше, но в будущем окупятся. Отдельный мобильный сайт, который визуально не отличается от мобильного приложения IOS, android будет ниже в выдачи адаптивного?
<button type=«submit» [disabled]="!reactiveForm.valid">
Код для Angular из apollo: