В этом сообщении блога я расскажу о других типах API, предоставляемых Hasura, т. е. API аутентификации. Эти API необходимы в любом приложении, и Hasura предоставила их пользователям, чтобы ускорить и упростить разработку. Это была, безусловно, самая сложная, а также самая интересная часть стажировки . Я немного поэкспериментировал в этой задаче просто потому, что хотел прояснить свои концепции (Нет лучшего способа открыть для себя что-то новое, чем копаться). У меня появилось огромное количество сомнений после просмотра вебинаров, связанных с моделированием данных и благодаря другим стажерам, мы их обсуждали и решали на форуме.
Я использовал Postman для всех запросов API. Как я уже говорил ранее, это замечательный инструмент, который может использовать каждый для тестирования своей СУБД и того, как она отвечает на запросы. Обратите внимание на детали запросов (таких как get /post , необработанный тип тела , объект JSON ), которые будут рассмотрены в следующей части. URL-адрес внешней конечной точки можно найти на консоли в меню Авторизация. Пользователь должен вставить его в адресную строку внутри Postman.
Вот ссылка на мою Коллекцию запросов Postman: https://www.getpostman.com/collections/4910a3072e043744c7f5
Hasura предоставляет разработчикам таблицу пользователей по умолчанию на консоли, которую можно использовать для управления пользователями с помощью веб-приложения . Он предоставляет три режима доступа: административный, пользовательский и анонимный. Самый первый пользователь, который входит в систему, по умолчанию получает режим "admin" . Он имеет неограниченный доступ ко всей базе данных. Затем последующим пользователям, вошедшим в систему, присваивается режим "user" . Мы можем установить ограничения на чтение/запись/вставку/удаление для этого режима, чтобы только пользователи, имеющие соответствующие права, могли запрашивать базу данных. Это помогает поддерживать конфиденциальность данных и предотвращает сбои в работе данных.
В основном Hasura предоставляет 4 типа API аутентификации:
- API регистрации: это основной API регистрации, используемый для создания нового пользователя в базе данных. Это запрос POST. Входной объект JSON состоит из имени пользователя и пароля, с которыми пользователь хочет зарегистрироваться. После успешного выполнения этого запроса в пользовательской таблице по умолчанию появится новая запись.
Вы можете видеть, что на скриншоте выше я пытался зарегистрироваться с комбинацией имени пользователя и пароля. Это было успешно, и я получил объект JSON с информацией о моем токене авторизации и моем «hasrua_id».
На приведенном выше снимке экрана я попытался снова зарегистрироваться с аналогичными учетными данными и получил сообщение об ошибке в ответе о том, что срок действия моего сеанса истек.
2. API входа в систему: после регистрации пользователь должен войти в систему, когда он хочет использовать приложение. Это запрос POST, аналогичный Signup API.
3. API информации об учетной записи: пользователь может узнать о своей информации с помощью API вещей. Вставьте его токен авторизации и другие детали, которые можно получить с помощью этого файла . Это запрос GET. Токен аутентификации конкретного пользователя, для которого вы хотите получить информацию, должен быть отправлен в заголовке запроса.
На приведенном выше снимке экрана я попытался найти информацию о пользователе с определенным токеном аутентификации.
4. API выхода: это простой API для выхода из приложения. Токен аутентификации пользователя отправляется в заголовке запроса. Это GET-запрос.
Токен аутентификации . Мне не совсем понятна концепция токена аутентификации . Я прочитал об этом в Интернете, а также получил помощь от нескольких друзей. Проще говоря, токен аутентификации идентифицирует конкретного пользователя и его запрос к приложению. В то время, когда в сети одновременно находятся сотни пользователей, нам нужна эта штука, чтобы определить, за чьим запросом следовать. Я зарегистрировался, используя комбинацию имени пользователя и пароля, и получил токен аутентификации. Когда я использовал этот токен для запроса данных, он работал нормально. В экспериментальных целях я изменил один символ токена, скопировал его в заголовок и снова отправил запрос в API. Теперь у меня вылезла ошибка, что введенный в шапке токен аутентификации не существует, что видно на скриншоте ниже. Таким образом, это разрешило мои сомнения.
Вот несколько снимков экрана моей базы данных после выполнения запросов и других операций CRUD вместе с авторизацией на месте.
Поэтому я убедился, что эта концепция кристально ясна, прежде чем двигаться дальше, иначе это привело бы к ненужным ошибкам на этапе тестирования.
Вот ссылка на мою схему в блоге:
https://medium.com/@varadhbhatnagar/data-modelling-hasura-internship-2017-79b81ea44adf
