hbrmdc: ну не совсем так, вы можете хранить JWT токен в куках, но это не удобно да и не нужно. Ну и само по себе хранение токена в local storage это не XSS уязвимость, просто если у вас есть XSS уязвимость то чувак может внедрить свой скрипт на страницу и стащить токен (и отправить его ajax-ом куда-нибудь). Но....
С куками вы делаете себя уязвивымими к CSRF атакам, с локал сторадж - к XSS атакам. Причем шутка в том что защититься нормально от обеих атак одновременно весьма сложно.
Но интересно еще вот что. От XSS защищаться нам надо всегда, а если нет кук - можно забить на CSRF. Вывод - можно хранить это дело в локал сторадже. в этом случае мы грустим только если злоумышленник крадет токен из браузера пользователя имея например физический доступ к его машине.
1) берем строку (в JWT это закадированный в base64 JSON, точнее две base64 JSON строки с разделителем в виде точки), вычисляем ее подпись (с приватным ключем высчитываем), отправляем на клиент.
2) когда пользователь делает запрос он присылает нам токен, если подпись верна - значит все хорошо. Подделать подпись можно только имея приватный ключ, который вы никогда никому не даете.
В этом случае ничего хранить сам токен не надо, а ID пользователя можно зашить в payload токена, и вообще какую-то несекьюрную но часто нужную инфу.
Есть сложные кейсы когда пользователю надо трекать все его сессии (например как у фэйсбуков и вконтактике) и тогда мы зашиваем ID сессии, в любом случае при аунтефикации лазать в базу не надо.
Doc: 1С это не программирование, это именно бухгалтерия, DSL (хреновенький) для описания бизнес процессов. Ну то есть разработчики 1C потом могут скажем в сторону менеджмента развиваться и т.д. Но для программиста это тупик в развитии. Просто чуть другая ветвь автоматизации процессов.
У меня например есть знакомые которые занимаются автоматизацией процессов на лотусе, и им все нравится. Они не программисты, а скорее бизнес аналитики.
Константин Нагибович: а вот меня всегда интересовало, 1С популярен только в СНГ. Весь остальной мир чаще использует всякие лотусы, решения от оракла и кучи других решений для организации бухгалтерии.
Etmac: это антипаттерн, когда логика отображения смешана с логикой обработки. ну то есть скорее не "смешана" а просто высокая связанность системы в этом плане. Где-то половина PHP разработчиков когда говорит что практикует MVC на самом деле ничего не разделяет.
Алексей Скобкин: по поводу чуда, все зависит от особенностей инструментов. Например у меня испльзуется Doctrine2 где используется unit-of-work. То есть запросы в базу оно генерит весьма эффективно, но внутри крутится очень много объектов, коллекции и т.д. так что PHP7 в моем случае дает нехилый прирост. По сути чем сложнее система и чем больше объекто крутится - тем больше профит.
sanns: о том что javascript намного проще C++, на нем можно писать не думая совершенно. То что вы называете сложностью и неожиданностями - называется "привычка".
romy4: socket-io есть только под node.js. Чего-то "такого же" с таким количеством готовых интеграций под все (фронтэнд, андроид, ios, да под что угодно есть клиенты) и с таким покрытием стандартных юзкейсов вы просто ничего не найдете.
А то что event loop можно организовать где угодно (с учетом того что библиотека libev доступна всем и каждому) это я не спорю. Я вот на PHP использую и libev и корутины, и доволен.
Но какой смысл использовать что-то другое, если на ноде требуемую функциональность (простенький RPC сервер с websockets) можно реализовать за пару часов даже ничего не зная о ноде.
crazy_str: я вас прекрасно понял, вы думаете что node.js это что-то "совсем другое не то что в браузере" и хотел вам просто сказать что с описанными вами уровнем знания javascript смысла учить ноду ровным счетом ноль.
Учить JS можно либо на MDN либо по javascript.ru (либо поищите тут аналогичные вопросы).
Далее по пунктам:
1) гугл транслейт и официальная дока, это просто список API, ничего сверх сложного и требующего чтения теории
2) как "аналогично"? PHP в отличии от node.js это язык программирования, node.js это платформа, интерпритатор JS + API для работы с вводом/выводом (по сети и файлы), а так же кое какие надстройки. Ну то есть javascript вам придется выучить отдельно.
3) я тоже самоучка, и обычно помимо примеров еще и документацию читаю и книги, и это как по мне намного более правильный путь. Примеры вам не скажут "вот так не делайте, потому что..."
crazy_str: перед тем как тыкать node.js вы должны хорошо разобраться с самим javascript, прекрасно понимать как работает event loop (это на клиенте можно тупить с этим) и т.д. А API ноды простое. Это просто API.
Евгений Попов: не вижу смысла в виду angular2. Да и использовать полимер с ангуляром тоже, полимер в принципе закрывает 90% того что мне надо от ангуляра.
Описанный вами алгоритм в принципе верен, а с JWT он просто в паре мест упрощается, так что...