В предыдущем упражнении
мы видели, как легко было для нас настроить, а затем
эшафот сервера получателей с помощью структуры LoopBack.
Мы видим, что эта структура LoopBack поддерживает весь
спектр конечных точек получателя и
все операции конечных точек получателя автоматически для нас,
когда мы эшафот нашего приложения.
В этом упражнении мы рассмотрим, как мы можем подключить
наш LoopBack сервер к внутренней базе данных,
или MongoDB в этом случае,
и мы также посмотрим, как мы можем настроить различные элементы управления доступом на конечных точках получателей.
Таким образом, используя элементы управления доступом,
мы можем указать, какие операции могут выполняться на конечных точках получателя,
и кому будет разрешено выполнять эти операции.
Так, например, неаутентифицированный пользователь или гость может
получить доступ только к информации или выполнить операцию get на конечных точках получателя,
аутентифицированный пользователь также сможет сделать то же самое,
но только администратор сможет записывать данные на мой сервер.
Таким образом, любые операции put, post и delete могут выполняться только администратором.
По пути мы также увидим, как мы можем настроить учетную запись администратора на нашем сервере LoopBack,
а затем настроить его так, что
только пользователь администратора будет разрешено выполнять эти операции.
Вот где LoopBack позволяет нам определить что-то,
называемое ролями, связанными с различными пользователями.
Таким образом, каждому пользователю может быть назначена роль.
В качестве примера можно говорить о обычном пользователе,
администраторе, супер-админе и так далее.
Таким образом, вы можете разделить свой набор пользователей на различные группы,
а затем назначить им различные роли.
Также мы рассмотрим, как встроенная пользовательская модель может быть дополнительно настроена,
в нашем приложении LoopBack,
и как мы можем построить другую модель поверх пользовательской модели,
а затем использовать пользовательскую модель в качестве базового класса
и разработать модель более высокого уровня под названием Customer Model,
которая позволяет нам хранить дополнительную информацию для каждого
из клиентов, которые войдут на наш сайт.
Итак, давайте рассмотрим некоторые из этих особенностей LoopBack в этом упражнении.
Чтобы начать с этого упражнения,
первое, что я хотел бы, чтобы вы сделали,
это запустить ваш сервер MongoDB.
Итак, здесь я нахожусь на другой вкладке терминала в моей папке MongoDB,
где я настраивал свой сервер MongoDB ранее,
который использовался моим сервером Express Plus MongoDB в предыдущих упражнениях.
Поэтому позвольте мне запустить сервер MongoDB, введя
Mongod минус данные части D-B
в этой папке, а затем запустить мой сервер MongoDB.
Теперь я собираюсь подключить свой сервер LoopBack к моему серверу MongoDB.
Поэтому, перейдя в мою папку сервера LoopBack здесь,
я должен запрашивать источник данных L-B.
Это позволит нам настроить источник данных для нашего сервера LoopBack.
LoopBack сам может одновременно подключаться к нескольким источникам данных, если вы так решите,
и он поддерживает различные виды.
Он поддерживает базы данных My Cycle, он поддерживает MongoDB,
он поддерживает Cloudant, который также является другой базой данных документов
, он поддерживает Oracle и многие другие виды баз данных.
Таким образом, вы можете легко настроить это.
В этом примере я собираюсь настроить свой сервер LoopBack
для разговора с моим MongoDB в бэкэнд.
Поэтому в ответ,
если мы
введем источник данных L-B, он предложит нам информацию.
Итак, первое, что он спросит нас, это имя источника данных,
а затем я настрою это имя источника данных как MongoDB,
а затем он предложит мне выбрать соединитель.
LoopBack использует соединители для подключения к различным базам данных за кулисами.
Как вы можете видеть, БД в памяти, которая является той, которую
они только что использовали в предыдущем упражнении,
но, конечно, БД в памяти означает, что после завершения работы сервера
все значения исчезнут,
и поэтому это не является постоянным хранилищем данных.
Итак, здесь вы видите различные виды баз данных, которые StrongLoop поддерживает здесь.
Таким образом, вы можете увидеть длинный список различных баз данных, которые поддерживаются.
Таким образом, вы можете видеть, что он поддерживает Cassandra, Redis,
мы кратко ссылались на них, когда мы говорили о базах данных NoSQL, MongoDB
, My SQL, PostGres, Oracle
и даже непосредственно на другие серверы API Rest для SOAP серверов,
Coachbase и так далее.
Таким образом, вы видите, что он
предоставляет нам длинный список различных видов источников данных оттуда,
наш сервер LoopBack может читать в информации.
В моем случае я собираюсь использовать сервер MongoDB, поэтому я
собираюсь настроить соединитель MongoDB.
Поэтому, когда я это сделаю,
LoopBack автоматически установит соединитель MongoDB для нас,
и когда он запрашивает URL-адрес строки соединения,
мы просто оставим это пустым, потому что мы позволим
ему использовать стандартный способ настройки.
Когда он запрашивает хост, мы скажем
localhost, потому что мы запускаем наш MongoDB на том же компьютере.
В противном случае вы укажете
имя хоста компьютера, на котором вы находитесь MongoDB работает.
Затем следующий - номер порта, и мы используем
наш стандартный номер порта MongoDB 27017,
и он также будет запрашивать имя пользователя и пароль, если это необходимо,
и прямо сейчас мой MongoDB работает без
какой-либо аутентификации, поэтому я оставляю имя пользователя и пароль пустыми,
и имя базы данных.
Имя базы данных на сервере MongoDB, который работает за кулисами,
имя базы данных там путаница.
Если вы помните, что это имя базы данных, которые они установили на нашем сервере MongoDB.
И тогда он спросит нас, должен ли он установить разъем LoopBack,
и я скажу да, и на
самом деле будет идти вперед и установить модуль NPM, который получает доступ к
разъему LoopBack к базе данных MongoDB.
И как только это будет сделано,
мой разъем Loopback установлен здесь, так что вы можете видеть, что это версия 1.18.1,
и мой сервер LoopBack готов поговорить с моим MongoDB.
Теперь, прежде чем я продолжу,
в предыдущем упражнении я действительно не настраиваю некоторые модели,
а затем я указываю их для хранения в БД,
мне нужно будет пойти и обновить их, чтобы сохранить свои данные в моем MongoDB.
Итак, давайте быстро сбросим наш код для сервера LoopBack.
Это также дает нам возможность посмотреть,
что мой сервер Loopback настроен в этой папке.
Открывая папку LoopBack в нашем редакторе,
вы можете увидеть, что Loopback уже имеет
эшафот из целой кучи файлов в эту папку.
Пакет.json, конечно, содержит
все связанные модули NPM, которые были настроены здесь,
и здесь вы можете видеть, что сам LoopBack сконфигурировал модуль NPM LoopBack,
загрузочный модуль LoopBack и, в
частности, позвольте мне обратить ваше внимание на LoopBack MongoDB ,
который мы только что установили недавно, и многие другие.
В частности, конфигурация для сервера Loopback
хранится в основном в файлах Json здесь,
с дополнительным javascriptcore всякий раз, когда это необходимо.
Мы рассмотрим настройку кода javascript немного позже.
Позвольте мне обратить ваше внимание на эту папку, называемую общей.
В этой общей папке
вы увидите все модели, которые мы настроили ранее.
Итак, вы увидите, что у нас есть файлы Dishes.JSON.
Поэтому, когда вы открываете файл dishes.json, вы видите, как LoopBack
хранит всю информацию о модели блюд, которую вы только что создали,
поэтому он имеет имя, базу
и некоторые другие значения здесь, которые он требует.
А затем посмотрите на свойства и как все свойства хранятся здесь.
Таким образом, вы видите некоторые вещи, которые очень легко для вас, чтобы
узнать, что они находятся в файле dishes.json.
Аналогичным образом, leaders.json и promotions.json.
Файл dishes.js большой,
мы можем добавить дополнительный код настройки для блюд,
но прямо сейчас мы не собираемся этого делать,
и поэтому мы просто оставим его как есть.
Таким образом, здесь вы можете добавить некоторый дополнительный код, который может
потребоваться выполнить при доступе к конечной точке косой черты.
Но сейчас мы оставим его пустым на данный момент.
Теперь давайте также посмотрим на папку сервера здесь.
И папка сервера,
в частности, позвольте мне обратить ваше внимание на файл datasources.json здесь.
В файле sources.json
все различные источники данных будут настроены здесь.
Итак, прямо сейчас у нас есть только БД, которая является
базой данных БД в памяти, которую LoopBack по умолчанию настраивает,
а затем MongoDB, который мы только что настроили,
только поглотил информацию, что вход
был сохранен в этих источниках данных, json-файле.
Таким образом, вы увидите, что сам LoopBack работает, настраивая все эти файлы,
которые сама структура LoopBack использует при
запуске сервера API отдыха на основе LoopBack.
Давайте перейдем в файл config.json модели здесь.
Сам файл config.json модели
хранит здесь много информации, которая полезна для нас,
но здесь, давайте входим и изменим несколько вещей.
Так что в этом, мы увидим, что есть снова для блюд,
акций и лидеров, источник данных был настроен как DB.
Поэтому мы собираемся изменить это на MongoDB здесь.
Не только для этого,
они также изменят это для продвижения, а также лидеров, что
означает, что все эти три будут получать свои данные из MongoDB.
Кроме того, для роли, которая определена здесь.
Мы также будем хранить в MongoDB.
Мы довольно скоро увидим, как мы будем использовать роль,
а также RoleMapping здесь.
Мы поймем причину этих двух через короткое время.
И затем, ACL, списки управления доступом,
они также будут храниться в MongoDB.
И тогда, пользователь, также,
мы сохраним его в MongoDB,
и тогда они оставят его там.
Таким образом, это изменения, которые вы должны сделать в
файле model-config.json, а затем сохранить изменения.
Как я уже упоминал ранее, Loopback по умолчанию
поддерживает эту модель называется, пользователь,
который используется для поддержки аутентификации пользователя.
Сама модель пользователя хранит только три различных свойства.
Имя пользователя, адрес электронной почты
и сведения, связанные с паролем.
Теперь, если они хотят иметь
более сложный способ хранения дополнительной информации о пользователях.
Затем они могут подклассифицировать эту модель базы пользователей,
а затем использовать ее.
Итак, на следующем шаге
я собираюсь создать еще одну модель под названием, модель клиента,
которая будет использовать пользователя в качестве базовой модели для его функционирования.
А сама модель клиента будет хранить дополнительную информацию о пользователях.
Итак, в модели клиента
я буду хранить такие вещи, как имя,
фамилия, и изображение для пользователя и так далее.
Таким образом, клиент будет действовать точно так же, как пользовательская модель,
которая уже поставляется с собственным набором методов.
Таким образом, пользовательская модель используется для аутентификации пользователя,
поэтому вы можете ввести имя пользователя и пароль,
а также войти и выйти из системы.
Таким образом, когда мы создали эту модель клиента на основе базового класса пользовательской модели,
модель клиента также будет поддерживать
операции входа и выхода из системы при использовании этой модели клиента.
Таким образом, мы можем войти в систему пользователя и выйти из него и так далее.
Таким образом, аутентификация пользователя автоматически приходит вправо.
Таким образом, чтобы создать модель клиента, в подсказке,
введите модель lb и для имени модели,
мы будем набирать Customer.
И DataSource, я выберу его как MongoDB.
И тогда, когда он просит выбрать базовый класс модели,
вместо использования PersistedModel,
мы будем двигаться вниз,
а затем выбрать пользователя в качестве базового класса.
Таким образом, он будет получать все свои свойства
базового пользовательского класса, который уже встроен в Loopback.
И тогда мы выставим это с помощью REST API
и пользовательского множественного числа MT.
И тогда это будет в общей папке.
И для этого, три свойства, которые мы добавим, являются
, имя, которое бы мы имели строку типов.
И это не обязательно или не имеет значения по умолчанию.
И затем фамилия снова в качестве строки типа,
не требуется, и нет значения по умолчанию.
И затем изображение строки типа,
не требуется и нет значения по умолчанию.
Таким образом, вы видите, что сам класс клиента
несет дополнительные свойства в дополнение к классу пользователя.
класс пользователя уже поддерживает имя пользователя,
адрес электронной почты и информацию, связанную с паролем.
Итак, класс клиента,
так как подкласс является базовым классом,
мы автоматически получим имя пользователя и электронную почту из класса пользователя.
И теперь, когда вы перейдете к файлу model-config.jason,
вы увидите, что модель клиента уже была добавлена туда.
А затем в общих моделях
вы увидите добавленный туда файл customer.json
с этими тремя дополнительными свойствами, которые мы добавили в модель клиента.
Но обратите внимание, что он указывает базу в качестве пользовательского класса для модели клиента здесь.
Итак, вот как Loopback позволяет вам взять
класс базовой модели, а затем подкласс, который в класс модели.
Итак, вы увидите, как Loopback позволяет нам автоматически поддерживать аутентификацию пользователей с помощью
пользовательского класса, а затем позволяет нам даже определить дополнительный подкласс этого,
который будет хранить дополнительную информацию, связанную с пользовательским базовым классом.
Далее мы настроим контроль доступа для
различных моделей, которые мы уже установили на нашем сервере Loopback.
Таким образом, чтобы настроить контроль доступа,
или списки управления доступом в Lookback.
Loopback использует эти списки управления доступом как способ указания того, какие
операции могут выполняться
на различных конечных точках REST API, соответствующих различным моделям.
Поэтому, чтобы сделать это, мы напечатаем в командной строке lb acl,
ACL означает списки управления доступом.
И тогда, когда это закончится, мы скажем, к
какой модели мы хотим применить этот список управления доступом.
А потом скажем, все существующие модели.
И мы скажем: «Все метрики и свойства».
И скажем,
все виды операций.
А потом, скажем, «Все пользователи».
И тогда мы скажем, явно запретить доступ.
Итак, мы сначала закрываем все модели для всего,
затем будем медленно открываться,
любые операции, которые могут быть выполнены разными пользователями.
Итак, первый шаг, мы закрыли
все типы операций на всех моделях, которые у нас есть в настоящее время.
Затем мы медленно начнем открывать каждую из операций, шаг за шагом.
Теперь следующий шаг,
то, что мы сделаем, это снова настроить следующий список управления доступом.
Во втором списке управления доступом мы скажем,
для всех существующих моделей и мы скажем,
Все метрики и свойства.
И тогда, скажем, только доступ к чтению.
То есть, когда пользователь может выполнять операции GET на этих конечных портах.
И эти GET операции могут выполняться всеми пользователями.
Таким образом, пользователи могут извлекать информацию.
И мы явно предоставим доступ для этого.
Таким образом, это означает, что операции GET разрешены на узле конечных точек REST API.
Сначала мы все закрыли,
потом открывали только GET операции для пользователей.
Теперь, наконец, они перейдут к каждой из моделей,
а затем закроют и разрешают определенные операции только
определенным типам пользователей.
Поэтому, чтобы сделать это,
следующий список ACL, который мы будем настраивать, предназначен для конкретной модели.
Итак, мы подставим эту для посуды.
И скажем, один метод.
И тогда имя метода: create.
Таким образом, это означает, что их создание будет разрешено только.
Итак, опять же, когда он говорит выбрать роль,
затем для роли, мы скажем, другое.
И тогда имя роли будет admin.
Итак, то, что мы делаем с помощью этой операции,
мы говорим, что только пользователь администратора может создавать новые блюда или обновлять существующие блюда.
Итак, это немного близко, остальные операции.
Итак, давайте сделаем то же самое для лидеров.
И один метод, а затем,
создание и мы скажем,
только администратор может это сделать.
И затем, наконец, также для промо-акций.
Для продвижения по службе.
Единственный метод, метод создания будет разрешен
только пользователями, которые имеют назначенную роль в качестве администратора.
Мы увидим, как мы будем создавать пользователей с определенной ролью на следующем шаге.
Явным образом предоставьте доступ.
Теперь обратите внимание, что я не закрывал клиентов для операций создания.
Если я закрою клиентов,
никто не сможет зарегистрироваться в системе.
Поэтому я оставлю это открытым.
Потому что клиент должен иметь возможность зарегистрироваться в системе.
Таким образом, вы можете подписаться на новые учетные записи в системе.
Учетные записи пользователей в системе.
Таким образом, это будет оставлено открытым для людей.
Таким образом, чтобы разрешить это для клиентов, мы скажем, клиенты,
Один метод, создать всех пользователей.
Таким образом, клиенты могут быть созданы всеми пользователями, потому что это
позволит людям войти в свою учетную запись.
Наконец, мы увидим, как мы можем настроить наш сервер для запуска
с одним пользователем администратора, автоматически настроенным на наш сервер Loopback.
Итак, чтобы сделать это, на
нашем сервере Loopback,
в папке сервера у нас есть эта загрузочная подпапка здесь.
Какой бы код мы ни поместили в загрузочную подпапку,
будет выполнен при запуске нашего сервера LoopBack.
Итак, здесь вы увидите, что у нас уже есть этот authentication.js,
который уже настроен,
Loopback, который будет настраивать аутентификацию пользователя для нас.
И тогда у нас есть root.js, который будет настраивать
некоторую дополнительную информацию для нашего сервера RAM Loopback.
И мы можем добавить дополнительные файлы здесь.
Итак, я собираюсь войти туда в папку загрузки,
а затем добавить в этот файл под названием script.js.
И в этом script.js
я собираюсь настроить код для создания пользователя администратора по умолчанию.
Итак, в script.js,
который будет не чем иным, как файловым модулем NPM, поэтому
мы начнем, сказав,
module.exports = function (app).
Приложение является приложением Loopback,
которое будет поставлено в качестве параметра этой функции для нас.
Итак, мы можем использовать его в нашем коде здесь.
Итак, здесь мы сначала настроим пользователя администратора.
Итак, чтобы сделать это, скажем,
var Customer = App.Models.Customer.
Таким образом, это дает нам доступ к модели клиента.
Тогда мы скажем, клиенты.
Итак, сначала мы проверим, если пользователь с
именем пользователя в качестве администратора уже настроен в системе или нет.
Если нет, то я собираюсь создать пользователя администратора.
И это предоставляет мне функцию обратного вызова с двумя параметрами, err и пользователями.
И внутри этого - Так что мы сначала попытаемся
увидеть, если пользователь с их именем admin уже существует.
Если пользователь не существует,
то мы создадим пользователя.
Итак, чтобы создать пользователя,
мы скажем здесь, если не пользователи.
Итак, если пользователи не являются нулевыми или если пользователь говорит null,
то это означает, что нет администратора, поэтому мне нужно создать пользователя администратора здесь.
Так что в этом случае, скажем, customer.create.
И это создание принимает массив объектов, если вы хотите.
И этот массив объектов позволит нам указать, какие учетные записи пользователей мы хотим создать.
Таким образом, первая учетная запись пользователя, которую я хочу создать, или
единственная учетная запись пользователя, которую я хочу создать, - это «Администратор».
Таким образом, это будет администратор по умолчанию для
моего сервера замыкания на себя, а затем я могу настроить электронную почту.
Поэтому напомним, что пользовательская модель поддерживает эти свойства,
confusion.net, а затем пароль,
который я настрою как пароль.
Вы также можете указать вместе с этим
имя и фамилию,
если хотите, для пользователя администратора.
Но я собираюсь оставить его как таковой,
как пустой, потому что они не требуются для пользователя администратора.
Так что я оставлю его там.
Таким образом, эта команда в конечном итоге создаст нового клиента с именем «Admin».
Так что если этот пользователь или имя «Admin» не существует,
то мы собираемся его создать.
А затем здесь у нас есть функция обратного вызова.
Так что заблуждайте пользователей.
Теперь я скажу,
если ошибки, мы не знаем, что он пытается сделать, поэтому мы просто выбросим ошибку.
Но обычно мы не ожидаем, что это произойдет.
Итак, как вы назначаете этого пользователя администратором?
Поэтому прямо сейчас, когда я
регистрируюсь здесь, я просто регистрирую обычного пользователя здесь,
но мы хотим дать особую роль этому пользователю.
Вот где loopback поддерживает способ указания ролей для пользователей.
Таким образом, чтобы указать роль,
мы будем var Role = App.models.role.
Таким образом, это позволит мне создать роль,
новую роль вызова администратора здесь.
Таким образом, мы можем назначить разные дроны разным пользователям, если вы хотите.
И вместе с этим
мне также нужно создать RoleMapapping здесь.
Так что скажем, App.models.Rolemapping.
И если так случится, что база данных уже содержит
какой-либо RoleMapping, который уже существует,
то я собираюсь уничтожить всех, когда я запускаю свой сервер.
А затем позвольте мне
попытаться найти,
существует ли в системе роль с этим именем admin.
Хорошо.
И в этом занимает,
как вы ожидали,
функцию обратного вызова и внутри здесь мы скажем, role.findone.
Поэтому, если роль с именем admin уже существует,
мне не нужно ее создавать.
В противном случае, если
этого не существует, мне нужно создать роль.
Так что мы скажем: «Роль.Создай».
Таким образом, мы создадим здесь роль администратора.
И тогда это приводит нас к параметрам err,
роли здесь, в функции обратного вызова.
Теперь снова, здесь, чтобы обработать ошибку,
мы просто скопируем это «если err», а затем вставьте его туда.
Точно так же здесь также, если происходит ошибка,
мне нужно справиться с этим.
Итак, «если ошибка», то «бросьте ошибку».
В противном случае мы создали эту роль.
Итак, теперь мне нужно сопоставить эту роль этому конкретному пользователю, которого я только что создал.
Этот пользователь, который я только что создал здесь.
Этот пользователь. Я хочу дать этому пользователю эту роль администратора.
Так как я создал эту роль по имени admin,
так что мы скажем, role.principals.create.
Вот как вы создаете сопоставление между ролью и конкретным пользователем здесь.
Так что скажем, role.principals.create.
Таким образом, это синтаксис.
Мы скажем, PrincipalType: RolemApping.User
здесь, и вы возьмете
идентификатор участника здесь, который является пользователями.
Теперь на что ссылается этот пользователь?
Эти пользователи ссылаются на это, что только что пришло.
Поэтому, когда мы создавали этих пользователей,
клиент должен создать успешный возврат к нам здесь.
Так вот, что я собираюсь использовать здесь.
Скажем, пользователи [0].
Таким образом, это будет массив пользователей, которые были созданы и содержат только один из них.
Поэтому я говорю, что пользователь [0].
И тогда мы назначим ID этого пользователя здесь.
Так мы создадим RoleMapping между ролью, которую мы только что создали,
этой ролью, а затем сопоставим ее с клиентом, который мы только что создали.
Теперь это также приводит нас к параметрам, функции обратного вызова.
И в этой функции обратного вызова мы просто скажем,
если (err) throw (err).
В противном случае мы не очень заинтересованы в том, чтобы знать, что еще там произошло.
Вот оно. Так вот как.
Поэтому, если роль с именем admin не существует,
мы создадим эту роль.
Если нет - Так это
часть «else», где мне все равно нужно будет сделать это сопоставление.
Так что позвольте мне скопировать этот код, а затем я сделаю именно это здесь.
Итак, role.principals.create, а затем сопоставить это для пользователя там.
Поэтому, если роль администратора уже существует,
тогда все, что им нужно сделать, это сопоставить.
Таким образом, это будет сохранено в модели RoleMapping в нашей базе данных. Вот оно.
Таким образом, этот фрагмент кода, который мы помещаем в файл script.js, сначала попытается
найти, существует ли пользователь администратора, и этот пользователь идентифицируется именем admin.
Если нет, то пользователь будет создан, а также затем создаст роль для пользователя.
Мы создадим роль с именем admin.
Если эта роль существует,
мы просто используем ее.
В противном случае мы создадим роль.
И после этого мы создадим это сопоставление между ролью и пользователем.
Таким образом, петля позволяет нам делать RoleMapping.
Таким образом, говоря, этот пользователь не относится к этой роли.
Таким образом, это сопоставление выполняется с помощью этого оператора.
Таким образом, это завершает настройку наших серверов.
Таким образом, пользователь администратора будет создан, и этот администратор
автоматически получит роль администратора, как указано здесь.
Вот оно. Давайте сохраним изменения в script.js.
И теперь наши серверы замыкания на себя должны быть готовы.
Итак, мы теперь пойдем и запустим наш сервер назад, а затем проверим, что мы можем сделать с этим.
Перейдя к терминалам,
давайте запустим сервер замыкания на себя.
Так что скажем, npm start, а затем наш сервер должен быть запущен и запущен.
Давайте перейдем к проводнику, а затем просмотрите информацию там.
И этот сервер loopback автоматически
подключается к моему MongoDP, потому что я установил соединение.
Перейдя в мой браузер,
позвольте мне перезагрузить это.
И когда я перезагружу это,
теперь вы увидите, что у нас есть новый клиент, который был создан здесь.
Пользователь уже существовал ранее.
Блюда, лидеры и акции все там.
Давайте выполним залезание на посуду.
Теперь, когда это связано с ртом MongoDB, у
моего MongoDB уже есть некоторые блюда.
Если ваш MongoDB пуст,
вы можете опубликовать некоторые блюда, используя пост здесь.
Так что давайте попробуем.
Когда я сделаю операцию на блюдах слэша,
вы увидите, что в теле ответа -
все блюда, которые существуют в моей базе данных, были извлечены.
Аналогично, я могу сделать GET по
акциям, и я должен увидеть продвижение, которое уже существует в моей базе данных там.
Таким образом, вы можете видеть, что продвижение уже существует там.
Это показывает нам, как мы можем получить информацию.
А теперь попробуем выложить новое блюдо.
Итак, чтобы разместить новое блюдо,
мы идем в POST здесь.
Позволь мне просто скопировать это.
Очевидно, в этот момент,
потому что так как я не вошел в систему,
мне не будет разрешено размещать блюдо так,
но я продемонстрирую, что вам просто скопировать и вставить эту информацию здесь,
и мы постараемся опубликовать это блюдо,
а затем, когда я попытаюсь разместить блюдо,
мой сервер немедленно отвечает с этой ошибкой, говоря: AUTRIZATION_REQUED.
Вы не уполномочены выполнять эту операцию.
Поэтому вы не уполномочены делать эту операцию.
Итак, как вы разрешаете себя?
Итак, чтобы авторизоваться,
теперь вспомните, что мы уже создали одного пользователя с именем admin,
и этот пользователь администратора уже существует как клиент здесь.
Таким образом, войдя в конечные точки REST API клиента,
если вы прокрутите
вниз, ниже здесь, вы увидите вход этого клиента.
Таким образом, когда вы выполняете POST при входе клиента.
Таким образом, для входа клиента
вы прокрутите здесь, а затем здесь он запрашивает учетные данные.
Итак, в учетных данных
мы можем ввести имя пользователя в двойные кавычки, и мы скажем,
Admin, а затем пароль,
мы скажем, пароль, и тогда мы опубликуем это.
И тогда, когда вы его
опубликуете, вы заметите, что в ответе
LoopBack отправит мне эту информацию обратно.
Теперь, в пределах этой информации,
этот конкретный идентификатор, который он отправляет обратно, является AccessToken для моего сервера LoopBack.
Итак, я могу просто скопировать этот AccessToken здесь,
а затем прямо в верхней части здесь,
вы можете видеть, что это Token Not Set, здесь.
Там написано «Токен не установлен».
И здесь вы можете ввести этот AccessToken,
а затем сказать: «Установить токен доступа».
И тогда ваш AccessToken будет установлен,
а затем все последующие операции, которые вы выполняете, автоматически переносят
этот AccessToken в заголовок моего сообщения запроса.
Итак, таким образом, теперь моему администратору будет разрешено делать сообщения элементов там.
Итак, теперь, когда я вошел в систему как администратор,
позвольте мне перейти на акции,
а затем я отправлю одну промо-акцию там
и покажу вам, что я действительно могу размещать рекламные акции.
Итак, давайте перейдем к POST,
а затем мы просто скопируем это, а затем в данных,
а затем для имени, которое мы скажем, Test promotion,
и изображение мы просто оставим его как таковое, описание, Test Description.
И я могу опубликовать его там,
и вы увидите,
что я не должен включать этот идентификатор здесь, потому что я
позволил LoopBack автоматически назначить ему идентификатор.
Позвольте мне опубликовать это, а затем вы увидите, что в теле ответа
продвижение теста было опубликовано здесь.
И я только что заметил, что я не включил
флаг для моих промо-акций и моих лидеров.
Итак, я собираюсь войти и включить флаг в качестве
одной из частей моих акций там.
Итак, теперь, когда я делаю GET для акций,
вы увидите, что в этом ответном сообщении
вы увидите старую акцию, которая уже была в моей базе данных,
а затем новую акцию, которую я только что разместил в моей базе данных, уже включенной здесь.
Итак, я только что заметил, что мне нужно установить флаг,
я покажу вам, как это сделать в.
Таким образом, этот вид демонстрирует вам, как вы можете войти в систему и исследовать ваш LoopBack сервер.
Позвольте мне уничтожить этот токен,
поэтому мы просто удалим токен,
а затем нажмите на него,
чтобы по существу отправить токен доступа в
пустую строку, и поэтому мой токен больше не будет обрабатывать,
поэтому теперь мой пользователь больше не входит в систему.
Позвольте мне создать нового клиента.
Итак, чтобы создать нового клиента я скажу, POST клиентов.
А потом я просто скопирую это отсюда.
Я создам себе новую учетную запись здесь.
Итак, здесь
я удалю область,
мне это не нужно, мне не нужен идентификатор
, поэтому для имени
и EmailVerified должны автоматически устанавливаться системой.
Итак, позвольте мне войти как этот пользователь.
Итак, я просто собираюсь отправить свое имя, фамилию
и изображение в настоящее время,
я просто установлю там пустую строку, имя пользователя и email.
И тогда мы попробуем его,
а затем он возвращается, говоря: «
Подробности»: «пароль» не может быть пустым.
Итак, вы заметите, что здесь
я также должен включить вместе с именем пользователя,
паролем, а затем, давайте опубликуем это.
Итак, когда вы его публикуете, он возвращается с
телом ответа, говорящим, что вы теперь являетесь частью системы.
Итак, ваше имя,
ваша фамилия и ваше имя пользователя, ваш идентификатор электронной почты
и идентификатор, который LoopBack назначает вам, отправляются вам обратно.
Итак, это не что иное, как идентификатор MongoDB, как вы можете видеть здесь.
Итак, теперь, когда я зарегистрировался как клиент,
я должен иметь возможность войти в систему как клиент,
так что я перейду в систему POST здесь,
а затем здесь вместо администратора,
я собираюсь войти в систему как новый пользователь, который я выполнил вход.
Итак, затем я нажимаю, чтобы попробовать его,
вы увидите, что он возвращается с идентификатором,
поэтому он дает мне токен для этого пользователя администратора здесь.
Таким образом, с этим мы завершили изучение сервера LoopBack, который мы только что создали.
И как я только что упомянул,
я заметил, что акции и лидеры не имеют флага, так что,
я собираюсь войти в код.
Итак, предположим, что вы забыли что-то подобное,
тогда вы можете просто войти и отредактировать код Json, если хотите.
Итак, я собираюсь войти в свой код, перейти
к коду,
я собираюсь сначала пойти в общее, а затем я пойду в dishes.json.
И затем в dishes.json,
я вижу это свойство признакам там.
Я собираюсь скопировать это свойство,
а затем я пойду в leaders.json,
а затем я вставлю это свойство функции в leaders.json,
а также с promotions.json.
Я забыл включить это, когда создал эти модели.
Я должен был сделать это, когда я создавал саму модель, поэтому,
если вы забыли что-то подобное,
то это еще один способ редактирования вашей модели,
а затем убедиться, что ваша модель настроена правильно.
Так вот и всё.
Итак, теперь мои акции и лидеры также будут иметь флаг, установленный там.
С этим мы завершаем это упражнение.
В этом упражнении мы видели, как мы можем настроить
новую модель путем расширения базового класса модели, который уже находится в LoopBack.
Мы также видели, как можно настроить элементы управления доступом, используя
списки контроля доступа, которые поддерживаются LoopBack.
С этим мы завершаем это упражнение.
Это хорошее время для вас, чтобы получить доступ к
сообщениям LoopBack источников данных и контроля доступа.