Как ограничить доступ к определенным свойствам объекта на основе запросачика

Question

Я новичок в MVC и создаю веб-приложение api для мобильного приложения. Я использую asp.net web api и структуру сущности.

Я много читал об аутентификации и авторизации для веб-api. Часть, о которой я не знаю, заключается в том, как предотвратить доступ к определенным свойствам объекта в зависимости от того, кто пытается получить доступ к свойству.

например. скажем, у моей модели есть объект закладок - сущность будет выглядеть следующим образом:

public class Bookmark 
{ 
    public long ID { get; set; } 
    public User Owner { get; set; } 
    public Boolean IsPublic { get; set; } 
} 

public class User 
{ 
    public string UserID { get; set; } 
    public DateTime DateJoined { get; set; } 
    public string Address {get;set;} 
    public virtual ICollection<Bookmark> Bookmarks { get; set; } 
} 

У меня есть два вопроса.

1) Пока кто-либо должен иметь доступ к ../mysite/username/bookmarks, если его другой человек запрашивает закладки другого человека, тогда я бы только возвращал общедоступные закладки. где должна жить эта логика? Я верю, что эта бизнес-логика должна быть в модели. Так должен ли я создать другой набор классов, таких как DTO, для обработки этой бизнес-логики? Я не видел примеров добавления таких методов к самим классам сущности.

2) Я заметил, что когда я возвращаю набор закладок из let say bookmarkController, потому что в Зале есть свойство User, он также возвращает свойства пользователя - включая информацию, которую я не хочу использовать - адрес.

Я не уверен, как (обнуляя свойства, прежде чем отвечать или назначая их различным DTO) и где я должен обрабатывать эти сценарии (добавление методов в DTO, специфичные для usecases или в контроллере).

Заранее спасибо.

Answer 1

Вы должны проверить, не является ли это другим человеком, запрашивающим закладки другого человека, и передать его логическому уровню. (что-то вроде: GetBookMatdData(int bookmarkID, bool isSamePerson)) , то если isSamePerson False, вы знаете, что не должны возвращать данные пользователя.

Answer 2

Возвращение DTO вместо классов сущностей EF обычно лучше. Он добавляет абстракцию, чтобы вы никогда (непреднамеренно) публично не раскрывали объекты, которые вы не хотите раскрывать. (Подумайте, что может случиться, если вы добавите чувствительные свойства позже).

Поэтому я обязательно вернусь BookMarkDto. Вы можете построить возвращенную коллекцию путем объединения всех общедоступных закладок и собственных закладок пользователя входа в систему. (Объединение неявно отличается). Таким образом, никто никогда не увидит чужие частные закладки.