как лучше всего ограничить услуги для определенных пользователей

РЕДАКТИРОВАТЬ: переформулировать и упростить вопрос для уточнения...

В моем сервисном слое у меня есть что-то вроде

GetAllMessages(string userid); 

В моей системе могут быть разные типы пользователей, такие как клиенты/поставщики и т. д.

Эта услуга доступна только для всех типов пользователей, однако как лучше всего реализовать услуги, доступные только избранным пользователям, например.

DeleteAllMessages(string userid); //client only
NewSupplierMessages(string userid); //supplier

Обычно эти методы находятся в одном классе с именем MessagesService.

ПРИМЕЧАНИЕ: просто чтобы уточнить, пользователь вошел в систему и аутентифицирован, однако мне интересно, должен ли я писать свои методы как таковые:

DeleteAllMessages(ClientUser user); //client only
NewSupplierMessages(SupplierUser userid); //supplier

В основном получайте информацию о пользователе для каждого действия и вызывайте методы более строго типизированным способом...

РЕДАКТИРОВАТЬ 2:

Обратите внимание, что мой доменный слой находится в отдельной библиотеке классов из моего веб-приложения, «пользователь-клиент» будет частью «клиента», аналогично «пользователь-поставщик» будет частью «поставщика», поэтому, если бы я хотел запросить мой сервисный уровень и вызвать правильный код (т.е. получить правильные данные) - я ДОЛЖЕН передать идентификатор пользователя или строго типизированный класс пользователя, я не могу понять, как иметь ограничение на объект DTO, который представляет, кто может получить доступ к сервису как неправильный/ломкий?

В противном случае у меня будет что-то вроде этого:

GetClientDetails();

Пользователь обрабатывается asp.net, поэтому мы знаем, что это действие может быть доступно пользователю, но что, если есть несколько клиентов? Конечно, тогда мы должны передать какой-то идентификатор клиента / если бы я должен был передать идентификатор пользователя, я мог бы получить от него идентификатор клиента...

Скорее я бы сказал, что мой доменный слой неверен, видя что-то вроде приведенной выше подписи...

РЕДАКТИРОВАТЬ 3: Единственная другая альтернатива, которую я мог придумать, это когда пользователь аутентифицируется, сохранить использование в классе с именем UserSession внутри приложения asp.net mvc в качестве глобального состояния, а затем внедрить его с помощью DI (внедрять) в уровень обслуживания моего домена, поэтому, когда мои подписи могут быть

GetClientDetails();

Класс службы домена, реализующий этот интерфейс, может быть:

public class ClientService : IClientWorkerService
{

    private ISession _session;
    private IGenericRepo = _repo;
    public ClientService(IUserSession _session, IGenericRepo _repo)
    {
      this._session = _session;
      this._repo = _repo;
    }

    public ClientDetails GetClientDetails()
    {
      var loggedonuser = _session.GetUser();

      if(!loggedonuser.isClient())
        throw new NoAccessException()

      return _repo.Single<Client>(x=> x.ClientID == loggedonuser.ClientID);
    }

}

person Haroon    schedule 14.06.2011    source источник
comment
Пожалуйста, рассмотрите возможность переформулировать свой вопрос более организованным образом. Опишите свою проблему, а затем задайте вопросы.   -  person Nix    schedule 14.06.2011


Ответы (1)


См. раздел MSDN: авторизация ASP.NET.

Авторизация определяет, должен ли удостоверению предоставляться доступ к определенному ресурсу. В ASP.NET существует два способа авторизации доступа к данному ресурсу:

Авторизация файлов

Авторизация файлов выполняется модулем FileAuthorizationModule. Он проверяет список управления доступом (ACL) файла обработчика .aspx или .asmx, чтобы определить, должен ли пользователь иметь доступ к файлу. Разрешения ACL проверяются для удостоверения пользователя Windows (если включена проверка подлинности Windows) или для удостоверения Windows процесса ASP.NET. Дополнительные сведения см. в разделе Олицетворение ASP.NET.

Авторизация по URL

Авторизация URL-адресов выполняется модулем UrlAuthorizationModule, который сопоставляет пользователей и роли с URL-адресами в приложениях ASP.NET. Этот модуль можно использовать для выборочного разрешения или запрета доступа к произвольным частям приложения (обычно каталогам) для определенных пользователей или ролей.

person YetAnotherUser    schedule 14.06.2011
comment
Я понимаю аутентификацию - я буду применять атрибуты/фильтры к своим контроллерам, чтобы предотвратить доступ определенных пользователей к моим контроллерам, мой вопрос больше в том, как я организую свой уровень DomainService для аутентифицированного пользователя. - person Haroon; 14.06.2011
comment
@Haroon, вот тут-то и появляется авторизация. Вы аутентифицировали пользователя, теперь вам нужно проверить, авторизован ли пользователь для выполнения определенного действия. Есть много способов реализовать это, хотя я думаю, что будет лучше, если вы сначала поймете, что авторизация отделена от аутентификации. - person YetAnotherUser; 14.06.2011
comment
Я хорошо разбираюсь в аутентификации, прежде чем я реализовал ее с помощью ModelValueProvider при вызове контроллера, однако я изменил свою таблицу пользователей, чтобы сделать всех частью одной пользовательской таблицы, поэтому мне интересно, следует ли мне придерживаться того, что я изложил выше в моем редактировать выше... - person Haroon; 14.06.2011
comment
Я бы не стал использовать эти подписи, это сделало бы код слишком хрупким. Я бы рекомендовал определить роли для каждого пользователя, а затем авторизовать каждый запрос на основе этих ролей. Для конкретной реализации вы можете посмотреть это. - person YetAnotherUser; 14.06.2011