ASP.Net Identity web api mvc architecture

Question

У меня есть вопросы об архитектуре идентификатора ASP.NET.

Это моя настройка.

1. Основное решение - бизнес, данных и Web API проектов
2. решение UI - проект MVC потреблять Web API

Я выполнил идентичность на веб-API с аутентификацией и авторизаций ,

Что я не понимаю, так это как я могу получить доступ ко всем материалам user.identity из пользовательского интерфейса, который находится в веб-службе api? Создать класс для моделирования приложения UserUser/IdentityUser после входа в систему? Кажется, что есть дублирование в классе User. Для меня я знаю, что авторизация выполняется в web api, поэтому не нужны все свойства. Но тогда, без списка разрешенных действий, как пользовательский интерфейс отображает авторизированные модули?

Выполняет ли пользовательский интерфейс только проверку подлинности пользователя в пользовательском интерфейсе и использование веб-службы для авторизации действий? Я рассматриваю это как проблему с разделением Mvc и Web API.

Answer 1

Если ваше приложение в значительной степени зависит от авторизации, вероятно, важно, чтобы ваш пользовательский интерфейс отражал авторизацию пользователя до того, как он совершил какое-либо действие. Например, если пользователь не уполномочен редактировать объект, тогда нет смысла представлять им кнопку «Изменить».

Если только информация, которую вы заинтересованы в том, что действия, которые они уполномочены сделать, то лучшим решением может продлить UserInfoViewModel класс, который возвращается в GetUserInfo() действия в AccountController.cs файле по умолчанию. Например, вы можете расширить его, чтобы включить свойство IsAdmin, или даже включить коллекцию Roles или Claims.

Answer 2

Почему вы отделяете веб-API и проекты MVC? Есть ли конкретная причина, по которой вы это делаете?

Если у вас есть два проекта, один из которых выставляет веб-API и один из них демонстрирует пользовательский интерфейс с использованием MVC, у вас будет два приложения , работающих на веб-сервере, с отдельными контекстами. Подумайте об этом как о создании приложения MVC UI для стороннего веб-сайта, предоставляющего веб-службы API.

Это означает, что внешнее приложение (MVC) должно аутентифицироваться во внутреннем приложении (веб-API) от имени пользователя и как-то хранить токен авторизации для последующего вызова API. Не знаете, как вы это достигли, но это можно сделать, используя переменную сеанса (не очень хорошая идея) или зашифрованный файл cookie авторизации.

Что внешнее приложение знает о зарегистрированном пользователе, это только то, что пользователь отправляет для аутентификации (например, имя пользователя или адрес электронной почты), и ответ, возвращаемый из проверки подлинности веб-API (который содержит токен и дату истечения срока действия).Если вам нужно больше информации во внешнем приложении (MVC), вам придется либо:

• Настройка аутентификации Web API, чтобы включить дополнительную информацию - см AspNet Identity 2: Customize OAuth endpoint response

• Добавить еще один сервис в ваше веб-приложение (Web API), которое возвращает любую информацию, которая может потребоваться для входа вошел в систему, и вызывать ее сразу же после аутентификации в приложении MVC.

И вам придется управлять/хранить возвращаемую информацию во внешнем приложении (MVC) самостоятельно.

Возможно, вам также потребуется настроить отдельное использование идентификатора ASP.NET для внешнего приложения (MVC) и использовать внутреннее приложение в качестве поставщика OAuth; но я не думаю, что это то, что вам нужно.

В любом случае, я думаю, вам нужно переоценить архитектуру и подумать о разделении проектов Web API и MVC. Если вы развертываете оба приложения в одном и том же месте, этот подход не только добавит большое количество неприятностей (например, управление авторизацией, о которой вы просите), но и это означает, что гораздо больше (ненужных) работы для сервера и более низкой производительности. И я не вижу никакой пользы, которую вы могли бы получить от такого разделения.