The authorization server MUST first verify the identity of the resource owner. The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.
Недавно с коллегами обсуждали такой кейс, будет интересно выслушать мнения :)
Есть сущность «купон», в базе есть как идентификатор (первичный ключ), так и уникальный код купона. Так как пользователь знает только этот код, он может оперировать только им. Соответственно сейчас наши эндпоинты выглядят как GET whatever/api/coupons/code/ для получения инфы по купону. На сколько это легально, учитывая, что код купона может содержать экранируемые символы (пробел, например)?
А на самом деле он слепил свой собственный неуклюжий фреймворк,… у него и получится обычный фреймворк, только зависящий от кучи разных библиотек, не протестированных на четкую работу вместе
В этом-то и идея PSRов, что реализуя интерфейс, не нужно тестировать взаимодействие, потому что оно гарантировано контрактом и тестами самой реализации.
Кроме того, что перевод сам по себе захватывающий, благодаря коммиту, на который ссылаются в последнем абзаце, я узнал о прекрасном теге <details> на Github!
Это не Docker way, таким образом у вас контейнер наследуется от чего-то базового и туда все складируется. Вы не сможете обновить только образ с нодой не затронув основной, вы не сможете сделать кластеризацию и балансировку между контейнерами.
Статье не хватает технических подробностей, без них она выглядит как промо-материал «какие мы молодцы, что сделали то, что хотели наши клиенты».
Например, какая у вас статистика запросов; сколько у вас серверов, чтобы выдерживать обновления каждые 1/25 сек.; какой стек технологий используется для реализации; etc…
Есть — собирать новый образ (долго), после чего останавливать запущенный контейнер (быстро) и тут же запускать его по-новой на уже собранном новом образе (так же быстро). Итого имеем очень маленький даунтайм
Вопрос возможно немного не по теме, все же:
После обновления докера до 1.9 контейнеры более не видят друг друга (даже с --link), говорят что нужно вручную создать сеть через docker network create и явно указать их при создании обоих контейнеров (--net). Знает кто-нибудь конкретнее?
Скажите пожалуйста, правильно ли я понял, что можно использовать рекурсивную стратегию слияния при ребейзе ветки, чтобы повторно не разрешать конфликты?
А используется ди preload для dev/stage? Как там происходит разработка, с учётом требования к restart/reload?
Недавно с коллегами обсуждали такой кейс, будет интересно выслушать мнения :)
Есть сущность «купон», в базе есть как идентификатор (первичный ключ), так и уникальный код купона. Так как пользователь знает только этот код, он может оперировать только им. Соответственно сейчас наши эндпоинты выглядят как GET whatever/api/coupons/code/ для получения инфы по купону. На сколько это легально, учитывая, что код купона может содержать экранируемые символы (пробел, например)?
В этом-то и идея PSRов, что реализуя интерфейс, не нужно тестировать взаимодействие, потому что оно гарантировано контрактом и тестами самой реализации.
Кроме того, что перевод сам по себе захватывающий, благодаря коммиту, на который ссылаются в последнем абзаце, я узнал о прекрасном теге
<details>на Github!К сожалению, не всегда. Я вот мержа моего багфикса в Symfony уже 4,5 месяца жду :(
А можно пример таких случаев?
А зачем хранить текстовые сообщения сразу с разметкой?
Например, какая у вас статистика запросов; сколько у вас серверов, чтобы выдерживать обновления каждые 1/25 сек.; какой стек технологий используется для реализации; etc…
После обновления докера до 1.9 контейнеры более не видят друг друга (даже с --link), говорят что нужно вручную создать сеть через docker network create и явно указать их при создании обоих контейнеров (--net). Знает кто-нибудь конкретнее?