Всем привет!
Сегодня у нас на сайте очень занятное обновление, а именно - авторизация через Metamask, то есть по сути через криптосеть Ethereum. И здесь есть парочка неожиданных моментов.
1. Вам не надо покупать крипту. Вообще никак. Вы просто ставите себе в браузер расширение Metamask, за минуту заводите в нем свой аккаунт и используете его для регистрации/авторизации на сайте.
2. Мгновенное взаимодействие. Многие слышали, что пропускная способность сети Этериум ограничена, транзакции часто зависают, и все это очень неудобно. Здесь этого нет. Все взаимодействие построено на чистом шифровании, без записи в блокчейн, просто на проверке цифровых подписей и идентификации отправителя подписанного сообщения. Как результат - все работает очень быстро, как будто это и вовсе не этериум.
3. Крипто-аккаунт в приоритете. Сама фишка в том, что теперь для регистрации не требуется указывать ни логин, ни емейл, ни пароль, ничего. Вы просто регистрируетесь через эфир и в дальнейшем ваша идентификация происходит через кошелек. А если у вас уже есть аккаунт здесь, авторизуйтесь и в личном кабинете увидите кнопку, чтобы привязать к аккаунт этериум-адрес.
4. Несколько аккаунтов на сайт. Конкретно здесь это не особо имеет смысл, но если вы разрабатываете сайт, на котором используется несколько уровней доступа, вам скорее всего захочется иметь возможность быстро переключаться между аккаунтами, при этом не придумывая логины, емейлы и пароли. В метамаске можно легко создавать сколько угодно адресов и использовать их для создания новых аккаунтов.
5. Один аккаунт для входа на несколько сайтов. Так как механизм авторизации един (Этериум - он везде Этериум), то один такой аккаунт можно использовать на любом призма-сайте.
При всем при том, это еще и полноценный Этериум-кошелек. Вы можете любым доступным способом пополнять кошелек, переводить между своими счетами, отправлять средства другим участникам сети и получать от них.
Как все это работает, смотрите в коротеньком видео.
Работает!
Браузерный Ethereum-кошелек MetaMask запустил публичное бета-тестирование своего мобильного приложения.
Оно позволяет управлять криптоактивами, отправлять пользователям ETH и токены стандартов ERC-20 и ERC-721 с помощью ENS-имен, и взаимодействовать с децентрализованными приложениями (dApps).
#новость
https://forklog.com/?p=77491
Ну и здорово:)
Николай, может стоит на главной странице или рядом с выбором языка, добавить ссылку на гит prinsma-cms? Ну и у вас "dfgfdg " болтается в левом нижнем углу.
И после публикации комментария, не обновляется форма -)
>> Николай, может стоит на главной странице или рядом с выбором языка, добавить ссылку на гит prinsma-cms?
ОК, воткну куда-нибудь.
>> Ну и у вас "dfgfdg " болтается в левом нижнем углу.
Да, в одну из зависимостей отладочная информация затесалась, оттуда уже убрал, но здесь пока не обновлял, потому что довольно много изменений прилетит, под которые и здесь код немного актуализировать надо будет (грядут новшества :)). Так что еще немного повисит, потом пропадет.
<< И после публикации комментария, не обновляется форма -)
Да, действительно не пропадает. Но возможно исправится после обновления компонентов (я там немного со сбросом кеша и коллбэками переделывал). Перепроверю дополнительно. Спасибо!
Вам спасибо!
Прошу прощения, что не в тему топика, но не могли бы вы просто, тезисно, рассказать об организации процесса авторизации на вашем сайте? Просто я пытаюсь мигрировать с php на js, сейчас разбираюсь с авторизацией и мне стало интересно какие способы хранения токена используют в реальных проектах. У вас на на сайте используется локальное хранилище, но насколько я знаю оно совсем не безопасно, этож те же куки только в профиль, разве нет? Вот сейчас в другом браузере открыл приватную вкладку, вбил туда свой токен и вуаля, я авторизован.
Выкатил обновления. Сейчас с сообщениями должно быть ОК. Заодно пофиксил давнюю багу с кешем комментариев: когда начинаешь писать коммент в одном топике, а потом замечаешь, что не туда пишешь, переходишь в другой, постишь коммент, а он улетает в исходный топик. Больше такой проблемы нет. При чем можно иметь сразу несколько черновиков комментариев в разных топиках (по одному на топик).
>>> Вот сейчас в другом браузере открыл приватную вкладку, вбил туда свой токен и вуаля, я авторизован.
Собственно так и должно быть, ведь у вас в наличии есть токен, созданый для идентификации пользователя. Есть токен валидный - есть авторизация.
Тут, конечно, стоит отдельно оговорить, что кукисы есть разные. Есть http-only, которые чаще всего и используются для хранения для PHP-сессий и которые не могут быть просто так прочитаны средствами JS (точнее вообще не должны ими читаться, а читаются и устанавливаются только серверными соединениями). Но http-only куки не панацея, и не являются обязательным механизмом авторизации. В современном интернете все чаще используют токены. В данном случае реализация на JWT. Статья на хабре: https://habr.com/ru/post/340146/
То есть в нашем случае используются именно токены, и это практически обязательно для принципа API-first CMS и т.п. Собственно, так изначально и был расчет: не важно на каком устройстве ты авторизовался и получил свой токен, ты его можешь в дальнейшем использовать где угодно (пока он принимается API-сервером). Так что ваша задача просто не слить свой токен кому попало. Хотя я соглашусь, что есть еще куда усиливать безопасность и позже я этим займусь. Но сейчас это пока преждевременная оптимизация.
И да, если вы хотите на своем проекте усилить авторизацию своими средствами, это можно.
Вот здесь токен создается, когда пользователь авторизовывается: https://github.com/prisma-cms/user-module/blob/7fc769cbf1635799442fdd798f6c2f209fa7a8c2/src/modules/index.mjs#L110
А вот здесь он проверяется, когда приходит API-запрос: https://github.com/prisma-cms/prisma-context/blob/8a4384ee6d3dbdc2e8eb67bdd2661a800cad5b18/src/index.mjs#L54
То есть используется следующий принцип при обработке запросов: когда на сервер приходит API-запрос, выполняется попытка идентифицировать пользователя. Если пользователь был получен, он добавляется в контекст текущего запроса, чтобы в процессе его обработки на всех уровнях GraphQL-резолверов его можно было получить из текущего контекста.
К примеру, практически все конечные серверные модули prisma-cms используют @prisma-cms/prisma-processor, и вот в нем выполняется попытка получить текущего пользователя: https://github.com/prisma-cms/prisma-processor/blob/375e361a3b2a46aeb4efd42b233dc3c08ec2e3b7/src/index.mjs#L286
То есть не выполняется запроса к БД или типа того, а просто он дергается из контекста.
В принципе я именно так, все себе и представлял. Но вчера при практической реализации подумал, что наверное все должно быть гораздо сложнее, плюс мой внутренний параноик начал бомбить.
Большое спасибо за развернутый ответ с примерами!
p.s. подтверждаю, багули пропали.
Не за что!
И еще раз уточню, на всякий случай: то, что записано в JWT, общедоступно и читаемо. То есть нельзя что-то приватное записывать в JWT. Хоть оно в виде обычной строки и человеконечитаемо, все-таки оно дешифруемо. Суть использования JWT в таком виде сводится к тому, чтобы не просто передать какие-то текстовые данные, а еще и подписать их для проверки подлинности в дальнейшем. То есть на стороне сервера вы создаете JWT-token (масло-масленое, ибо аббревиатура JWT уже включает в себя Token), используя ключ, который никто не должен знать, потому как есть знает, он может модифицировать запись и подписать ее этим ключом, и тогда сервер примет этот токен, что совсем не есть хорошо. Этот момент надо четко понимать. А то некоторые, видя нечитаемую строку, думают, что в нее можно записывать все, что угодно. Нет, это совсем не так.