— access_token не нужно хранить в базе данных, с помощью JWT можно хранить данные в токене — например userId, таким образом при каждом запросе к серверу мы избавляемся от лишнего запроса к базе данных так как ID юзера можно получить из токена
— refresh_token хеш который хранится в базе данных.
1. Сервер получает логин/пароль — создает access_token и refresh_token, сохраняет в базу refresh_token, отдает токены на клиент
2. Клиент использует access_token для доступа к данным пока приложение не будет закрыто, сохраняет refresh_token в хранилище
3. Если получает от сервера сообщение что срок access_token истек — отправляет запрос на авторизацию с refresh_token, если refresh_token не истек и совпадает с тем что в базе — сервер создает access_token и refresh_token, обновляет в базе refresh_token и отдает на клиент. Если refresh_token не валиден просит ввести логин/пароль
4. При инициализации приложения если есть refresh_token — делает тоже что и в 3
Почему в статье даже мельком не упомянуто, как работать с персистентными данными (например, СУБД) в идеологии докера? Ведь про то, что stateless "Hello world" замечательно ложится на концепцию, это и без статьи понятно...
Вот есть, например, система, и в качестве СУБД используется Постгрес. Что дальше? Все рассуждения про "легкость перезапуска" оказываются вдруг неприменимы?
Есть незаслуженно обделённая вниманием мулинекс cook4me.
Мультиварка-пароварка, чашка на 6л, с большими удобными ручками
С паром всё сама, попищит, когда стравливает давление, так как было на картинке, руками к клапану лезть не надо.
Кукурузу варит в 10 минут.
Большая пачка вшитых рецептов, причем отдельно по блюдам, отдельно по ингредиентам.
Меню удобное, управление — один энкодер с кнопкой, и отдельная кнопка отмены. Полифония, 65354 цветов
Из минусов — нет мануального режима с установкой температуры,
есть мануальный режим с выбором «режима готовки», поджаривание — быстрая готовка(под давлением) — подогрев.
Мелодия не меняется, залить новую нельзя (-
Начну с традиционного вопроса — удобно ли им копать?
Менее традиционные — вы можете одной рукой поднять баскетбольный мяч с пола?
Просто, как мне кажется, только такие люди могут комфортно работать на пятидюймовых экранах одной рукой.
Существуют ли в природе 4х дюймовые телефоны на МТ6589? (ну ладно, чёрт с вами, пускай будет 4.5")
Нет. У git нет API, позволяющего нормальную интеграцию с чем‐либо (делать каждый раз fork-exec и читать выхлоп из pipe — это очень медленно, как в смысле скорости разработки так и скорости исполнения. Даже несмотря на то, что интеграция пишется на языке, который успешно прячет fork-exec).
У git нет огромного количества хуков (например, preoutgoing, все pre-{command}, …).
У git нелогичное распределение функциональность по командам: checkout создаёт ветки или обновляет дерево, push отправляет изменения или удаляет их на том конце, diff может показывать изменения между ревизиями, а может — status, причём сам status этого не умеет…
У git иногда плохая обработка аргументов командной строки (pull принимает сначала аргументы для merge, затем для fetch).
У git плохая документация — она настолько подробна, что отыскать нужное зачастую не представляется возможным. Вместе с неочевидным распределением функциональности по командам это создаёт проблемы.
Аналог revsets у git обладает куда как меньшими возможностями.
Многие команды git, показывающие список ревизий, не имеют возможности настройки формата вывода.
У часто используемых команд вроде push/pull есть ненужные обязательные аргументы: «git push origin :branch».
У git нет аналога «hg incoming».
У git нет удобного аналога «hg grep».
Большую часть претензий можно игнорировать или терпеть. Но не первые две.
Мейл.рушная команда самая жадная, беспринципная и подлая в рунете. Сначала они заманили девелоперов нулевой комиссией, маркетинговыми бонусами. Буквально тут стелились на Хабре. Потом склонировали самые удачные приложения. Подняли в два этапа комиссию. Удалили мешающие им приложения. Ужесточили правила. Крутили в свою сторону рейтинги и вуаля — выжали все что можно с платформы.
Сосут с бедных домохозяек деньги за вилы на фермах и корм виртуальным котятам, но им недолго осталось. 1-2 года и кормушка иссякнет, людям захочется поинтереснее, а все уже на мобилах. Нормальные разработчики не забудут, не простят.
Хватит копипастингом заниматься, есть статьи Дмитрия Сошникова который просто гениально описал все внутренностие JS, что откуда вытекает и почему. Ваша статься больше похожа на неосознанный поток слов, без структуры.
Наравне с пользовательскими репозитариями также удобно пользоваться пользовательскими QueryBuilder'ами, куда запирать общие части запросов. Тогда сами запросы внутри методов репозитория будут компактнее и читаемее + для каждого репозитория может существовать (или не существовать) свой класс QueryBuilder'а.
Пример продвинутого метода репозитория:
public function fincAllActive()
{
return $this->getQueryBuilder('users')->onlyActive()->getResult();
}
Соответственно — в QueryBuilder'е есть такие методы:
public function getResult()
{
return $this->getQuery()->getResult();
}
public function onlyActive()
{
return $this
->andWhere($this->getAlias() . '.active = :activeStatus')
->setParameter('activeStatus', true);
}
Пример начала миграции к такому подходу в рабочем проекте:
В этой схеме очень много железа, а толку мало.
1) MySQL и апач можно держать на одном физическом сервере. Дело в том, что mysql нагружает диски, а апач нагружает процессор и они довольно сносно уживаются на одном сервере. В результате мы на выделенном железе (6 серверов) запросто можем собрать 4 комплекса (mysql + apache — апач ходит только к своему mysqlю на том же физическом сервере) и настроить между ними репликацию.
2) Оставшиеся 2 сервера вынесем вверх принимать входящие запросы с настройкой между ними heartbeat. На серверах установим nginx в качестве балансера на 4 бекендных комплекса (mysql+апач).
3) В результате мы увеличили общую производительность в 2 раза на все тех же 6 серверах! :)
читая посты TravisBickl'а, я прям разрываюсь каждый раз. с одной стороны, просто офигительнейший функционал, на который нужно потратить несколько месяцев разработки, и это очень полезный и нужный функционал, и он работает, и его можно просто так взять и скачать и даже спросить человека который его написал. с другой стороны, вот этот код вгоняет меня в ступор. xor eax,eax какой-то. и в то же время код работает, и внутренняя логика в этом коде тоже есть. но как эта логика мне чужда, её как будто писал инопланетянин. но этот инопланетянин хороший программист, судя по единому стилю написания кода и его функциональности. но каков он, этот стиль!
и так каждый раз. мучаюсь.
Фирма в Праге. Виза в Москве. Фирм-проживачек вообще-то ;-)
У меня вполне нормальная фирма, с банковским счетом, офисом, и всеми документами. Те кто снимает деньги — кидалы, я с такими не играю в одной песочнице.
И будет еще один openid провайдер(как жжшечка) не возвращающий мыльник. ^_^ ибо вконтактовский getProfiles vkontakte.ru/pages.php?o=-1&p=getProfiles мыло не отдает.
То есть для регистрации по openid на многих сайтах оно не подойдет.
У… опять. Дело ibnteo живёт и процветает.
Поясняю.
base64 не повышает криптостойкости. Отбрасываем.
Пространство ключей (любые символы, любое количество) намного больше пространства хэшей от ключей (32 знака от 0 до F).
По определению односторонних функций, потому есть коллизии.
Пространство хэшей от хэшей, еще меньше.
Хабровчане, воистину, не хешируйте хешированное!
Я понимаю, что это была ирония, но на всякий пожарный, вдруг в своих проектах используете.
— access_token не нужно хранить в базе данных, с помощью JWT можно хранить данные в токене — например userId, таким образом при каждом запросе к серверу мы избавляемся от лишнего запроса к базе данных так как ID юзера можно получить из токена
— refresh_token хеш который хранится в базе данных.
1. Сервер получает логин/пароль — создает access_token и refresh_token, сохраняет в базу refresh_token, отдает токены на клиент
2. Клиент использует access_token для доступа к данным пока приложение не будет закрыто, сохраняет refresh_token в хранилище
3. Если получает от сервера сообщение что срок access_token истек — отправляет запрос на авторизацию с refresh_token, если refresh_token не истек и совпадает с тем что в базе — сервер создает access_token и refresh_token, обновляет в базе refresh_token и отдает на клиент. Если refresh_token не валиден просит ввести логин/пароль
4. При инициализации приложения если есть refresh_token — делает тоже что и в 3
Вот есть, например, система, и в качестве СУБД используется Постгрес. Что дальше? Все рассуждения про "легкость перезапуска" оказываются вдруг неприменимы?
Скорость синхронизации мгновенная
Мультиварка-пароварка, чашка на 6л, с большими удобными ручками
С паром всё сама, попищит, когда стравливает давление, так как было на картинке, руками к клапану лезть не надо.
Кукурузу варит в 10 минут.
Большая пачка вшитых рецептов, причем отдельно по блюдам, отдельно по ингредиентам.
Меню удобное, управление — один энкодер с кнопкой, и отдельная кнопка отмены.
Полифония, 65354 цветовИз минусов — нет мануального режима с установкой температуры,
есть мануальный режим с выбором «режима готовки», поджаривание — быстрая готовка(под давлением) — подогрев.
Мелодия не меняется, залить новую нельзя (-
По цене выходит подороже, market.yandex.ua/offers.xml?modelid=8529595&hid=4954975&hyperid=8529595&grhow=shop чтото вроде того.
Вам следовало бы использовать встроенные методы $.widget, что-то вроде:
Менее традиционные — вы можете одной рукой поднять баскетбольный мяч с пола?
Просто, как мне кажется, только такие люди могут комфортно работать на пятидюймовых экранах одной рукой.
Существуют ли в природе 4х дюймовые телефоны на МТ6589? (ну ладно, чёрт с вами, пускай будет 4.5")
У git нет огромного количества хуков (например, preoutgoing, все pre-{command}, …).
У git нелогичное распределение функциональность по командам: checkout создаёт ветки или обновляет дерево, push отправляет изменения или удаляет их на том конце, diff может показывать изменения между ревизиями, а может — status, причём сам status этого не умеет…
У git иногда плохая обработка аргументов командной строки (pull принимает сначала аргументы для merge, затем для fetch).
У git плохая документация — она настолько подробна, что отыскать нужное зачастую не представляется возможным. Вместе с неочевидным распределением функциональности по командам это создаёт проблемы.
Аналог revsets у git обладает куда как меньшими возможностями.
Многие команды git, показывающие список ревизий, не имеют возможности настройки формата вывода.
У часто используемых команд вроде push/pull есть ненужные обязательные аргументы: «git push origin :branch».
У git нет аналога «hg incoming».
У git нет удобного аналога «hg grep».
Большую часть претензий можно игнорировать или терпеть. Но не первые две.
Сосут с бедных домохозяек деньги за вилы на фермах и корм виртуальным котятам, но им недолго осталось. 1-2 года и кормушка иссякнет, людям захочется поинтереснее, а все уже на мобилах. Нормальные разработчики не забудут, не простят.
Во что хабр превращается, постоянно одно и тоже:
habrahabr.ru/post/48542/
habrahabr.ru/post/133034/
habrahabr.ru/post/40909/
habrahabr.ru/post/94070/
habrahabr.ru/post/68004/
habrahabr.ru/post/131714/
habrahabr.ru/post/108915/
habrahabr.ru/post/124327/
Можете меня заминусовать, но хватит засирать хабр, научитесь искать, научитесь писать свои мысли!
Все кому интерес javascript идем и читаем dmitrysoshnikov.com/ecmascript/ru-javascript-the-core/ читаем, читаем, читаем
Пример продвинутого метода репозитория:
public function fincAllActive()
{
return $this->getQueryBuilder('users')->onlyActive()->getResult();
}
Соответственно — в QueryBuilder'е есть такие методы:
public function getResult()
{
return $this->getQuery()->getResult();
}
public function onlyActive()
{
return $this
->andWhere($this->getAlias() . '.active = :activeStatus')
->setParameter('activeStatus', true);
}
Пример начала миграции к такому подходу в рабочем проекте:
репозитоий:
github.com/litecommerce/core/blob/1.0-master/src/classes/XLite/Model/Repo/ARepo.php#L1257
QueryBuilder:
github.com/litecommerce/core/blob/1.0-master/src/classes/XLite/Model/QueryBuilder/AQueryBuilder.php
Активного использования пользовательского QueryBuilder'а там нету — но будет :)
1) MySQL и апач можно держать на одном физическом сервере. Дело в том, что mysql нагружает диски, а апач нагружает процессор и они довольно сносно уживаются на одном сервере. В результате мы на выделенном железе (6 серверов) запросто можем собрать 4 комплекса (mysql + apache — апач ходит только к своему mysqlю на том же физическом сервере) и настроить между ними репликацию.
2) Оставшиеся 2 сервера вынесем вверх принимать входящие запросы с настройкой между ними heartbeat. На серверах установим nginx в качестве балансера на 4 бекендных комплекса (mysql+апач).
3) В результате мы увеличили общую производительность в 2 раза на все тех же 6 серверах! :)
и так каждый раз. мучаюсь.
У меня вполне нормальная фирма, с банковским счетом, офисом, и всеми документами. Те кто снимает деньги — кидалы, я с такими не играю в одной песочнице.
То есть для регистрации по openid на многих сайтах оно не подойдет.
Поясняю.
base64 не повышает криптостойкости. Отбрасываем.
Пространство ключей (любые символы, любое количество) намного больше пространства хэшей от ключей (32 знака от 0 до F).
По определению односторонних функций, потому есть коллизии.
Пространство хэшей от хэшей, еще меньше.
Хабровчане, воистину, не хешируйте хешированное!
Я понимаю, что это была ирония, но на всякий пожарный, вдруг в своих проектах используете.