Как стать автором
Обновить
6
0

Пользователь

Отправить сообщение
Разница между access_token и refresh_token:

— 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

Есть еще совершенно простой и безболезненный способ, выбирать одновременно вместе с данными:

SELECT stuff,
       count(*) OVER() AS total_count
FROM table
WHERE condition
ORDER BY stuff OFFSET 40 LIMIT 20
Почему в статье даже мельком не упомянуто, как работать с персистентными данными (например, СУБД) в идеологии докера? Ведь про то, что stateless "Hello world" замечательно ложится на концепцию, это и без статьи понятно...

Вот есть, например, система, и в качестве СУБД используется Постгрес. Что дальше? Все рассуждения про "легкость перезапуска" оказываются вдруг неприменимы?
Для синхронизации локальной версии проекта с хостом можно использовать realsync. Работает на основе rsync.
Скорость синхронизации мгновенная
Есть незаслуженно обделённая вниманием мулинекс cook4me.
Мультиварка-пароварка, чашка на 6л, с большими удобными ручками
С паром всё сама, попищит, когда стравливает давление, так как было на картинке, руками к клапану лезть не надо.
Кукурузу варит в 10 минут.
Большая пачка вшитых рецептов, причем отдельно по блюдам, отдельно по ингредиентам.
Меню удобное, управление — один энкодер с кнопкой, и отдельная кнопка отмены.
Полифония, 65354 цветов

Из минусов — нет мануального режима с установкой температуры,
есть мануальный режим с выбором «режима готовки», поджаривание — быстрая готовка(под давлением) — подогрев.
Мелодия не меняется, залить новую нельзя (-

По цене выходит подороже, market.yandex.ua/offers.xml?modelid=8529595&hid=4954975&hyperid=8529595&grhow=shop чтото вроде того.
«… во время весеннего гона маркетологов».
Странное решение, на мой взгляд. Это же детище несравненного jQuery.widget.

Вам следовало бы использовать встроенные методы $.widget, что-то вроде:
$.widget('custom.datepicker', $.ui.datepicker, {
    _attachHandlers: function(inst) {
        // ROCK
    }
});
Начну с традиционного вопроса — удобно ли им копать?
Менее традиционные — вы можете одной рукой поднять баскетбольный мяч с пола?
Просто, как мне кажется, только такие люди могут комфортно работать на пятидюймовых экранах одной рукой.

Существуют ли в природе 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, что откуда вытекает и почему. Ваша статься больше похожа на неосознанный поток слов, без структуры.

Во что хабр превращается, постоянно одно и тоже:
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/ читаем, читаем, читаем

Недавно опробовал MangoDB(написана разработчиком из DISQUS на python), так она рвет по производительности MongoDB и все остальные скоростные бд!
Наравне с пользовательскими репозитариями также удобно пользоваться пользовательскими 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);
}


Пример начала миграции к такому подходу в рабочем проекте:

репозитоий:
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 серверах! :)
читая посты TravisBickl'а, я прям разрываюсь каждый раз. с одной стороны, просто офигительнейший функционал, на который нужно потратить несколько месяцев разработки, и это очень полезный и нужный функционал, и он работает, и его можно просто так взять и скачать и даже спросить человека который его написал. с другой стороны, вот этот код вгоняет меня в ступор. xor eax,eax какой-то. и в то же время код работает, и внутренняя логика в этом коде тоже есть. но как эта логика мне чужда, её как будто писал инопланетянин. но этот инопланетянин хороший программист, судя по единому стилю написания кода и его функциональности. но каков он, этот стиль!
и так каждый раз. мучаюсь.
Фирма в Праге. Виза в Москве. Фирм-проживачек вообще-то ;-)
У меня вполне нормальная фирма, с банковским счетом, офисом, и всеми документами. Те кто снимает деньги — кидалы, я с такими не играю в одной песочнице.
И будет еще один openid провайдер(как жжшечка) не возвращающий мыльник. ^_^ ибо вконтактовский getProfiles vkontakte.ru/pages.php?o=-1&p=getProfiles мыло не отдает.
То есть для регистрации по openid на многих сайтах оно не подойдет.
У… опять. Дело ibnteo живёт и процветает.
Поясняю.
base64 не повышает криптостойкости. Отбрасываем.

Пространство ключей (любые символы, любое количество) намного больше пространства хэшей от ключей (32 знака от 0 до F).
По определению односторонних функций, потому есть коллизии.

Пространство хэшей от хэшей, еще меньше.

Хабровчане, воистину, не хешируйте хешированное!

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

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность