В Web API имеются авторизационные фильтры, где можно проверять роли или клеймы. Это существует давно и работает, но как быть в случае, когда декларативно обьявить правила нельзя, например методы
public GetProducts()
public UpdateProduct(productID int)
Как проверить в фильтре, что у текущего пользователя есть права на update определенного продукта (скажем может обновлять продукт c id = 123, а другие может только читать.) Или может читать только c id > 123. Все эти правила требуют доступ к БД для проверки. Традиционно это делается прямо в методе, т.е. добавляется что-то типа
if (AccessAllowed(productID, userID))...
либо
select * from Products join UserProducts ...
Хотелось-бы отделить логику безопасности от бизнес-логики, удавалось-ли это кому-нибудь?
Re: Autherisaton фильтры с недекларативной логикой
Здравствуйте, Stalker., Вы писали:
S>В Web API имеются авторизационные фильтры, где можно проверять роли или клеймы. Это существует давно и работает, но как быть в случае, когда декларативно обьявить правила нельзя, например методы
S>
S>Как проверить в фильтре, что у текущего пользователя есть права на update определенного продукта (скажем может обновлять продукт c id = 123, а другие может только читать.) Или может читать только c id > 123. Все эти правила требуют доступ к БД для проверки. Традиционно это делается прямо в методе, т.е. добавляется что-то типа
S>
S>if (AccessAllowed(productID, userID))...
S>
S>либо
S>
S>select * from Products join UserProducts ...
S>
S>Хотелось-бы отделить логику безопасности от бизнес-логики, удавалось-ли это кому-нибудь?
У меня был проект(не web-api) там были классы, которые отвечали за аутентификацию и авторизацию. Все шло через них. Так что выделить можно, а в некоторых случаях и полезно. А что разве в Web-api нельзя свой фильтр написать?
Программа – это мысли спрессованные в код
Re[2]: Autherisaton фильтры с недекларативной логикой
Здравствуйте, Qulac, Вы писали:
Q>У меня был проект(не web-api) там были классы, которые отвечали за аутентификацию и авторизацию. Все шло через них. Так что выделить можно, а в некоторых случаях и полезно. А что разве в Web-api нельзя свой фильтр написать?
можно, но может существуют какие-то рекомендованные паттерны. Скажем пример метода чтения только с id > 100. Можно прочитать все, а потом в фильтре отфильтровать все лишние значения. Но как-то это странно будет выглядеть, много лишнего кода на ровном месте, не говоря уже про производительность.
Re[3]: Autherisaton фильтры с недекларативной логикой
Здравствуйте, Stalker., Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>У меня был проект(не web-api) там были классы, которые отвечали за аутентификацию и авторизацию. Все шло через них. Так что выделить можно, а в некоторых случаях и полезно. А что разве в Web-api нельзя свой фильтр написать?
S>можно, но может существуют какие-то рекомендованные паттерны. Скажем пример метода чтения только с id > 100. Можно прочитать все, а потом в фильтре отфильтровать все лишние значения. Но как-то это странно будет выглядеть, много лишнего кода на ровном месте, не говоря уже про производительность.
Не очень понятно чего вы хотите. Выдавать разные данные разным пользователям — это одно, а защита доступа это другое.
Программа – это мысли спрессованные в код
Re[4]: Autherisaton фильтры с недекларативной логикой
Здравствуйте, Qulac, Вы писали:
Q>Не очень понятно чего вы хотите. Выдавать разные данные разным пользователям — это одно, а защита доступа это другое.
Выдавать разные данные разным пользователям — это и есть защита доступа Только она не декларативная. Т.е. зависит от настроек. Упрощенно есть товары, к ним у разных пользователей разные уровни доступа на чтение/изменение. Это совершенно определенно логика доступа, и вопрос в том, как ее эффективно отделить от бизнес логики. Если ее влоб впихнуть в бизнес логику (что обычно и происходит), то начинается размазывание этого кода по всей системе.
Re[5]: Autherisaton фильтры с недекларативной логикой
Здравствуйте, Stalker., Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Не очень понятно чего вы хотите. Выдавать разные данные разным пользователям — это одно, а защита доступа это другое.
S>Выдавать разные данные разным пользователям — это и есть защита доступа
Спорно. Это еще не гарантирует того, что пользователь не сможет изменить объект с доступом "только для чтения", т.е. все равно нужно будет делать еще проверки. По мне это ближе к бизнес-логике.
Q>> Только она не декларативная. Т.е. зависит от настроек. Упрощенно есть товары, к ним у разных пользователей Q>>разные уровни доступа на чтение/изменение. Это совершенно определенно логика доступа, и вопрос в том, как ее Q>>эффективно отделить от бизнес логики.
Q>>Если ее влоб впихнуть в бизнес логику (что обычно и происходит), то начинается размазывание этого кода по всей Q>>системе.
Наверное так лучше и сделать, ведь объекты с разным функционалом(чтение или запись) возвращаются к пользователю не просто так, а в рамках какой-то бизнес-логики, соответственно в ней это и будет отражено.
Программа – это мысли спрессованные в код
Re[6]: Autherisaton фильтры с недекларативной логикой
Здравствуйте, Qulac, Вы писали:
Q>Наверное так лучше и сделать, ведь объекты с разным функционалом(чтение или запись) возвращаются к пользователю не просто так, а в рамках какой-то бизнес-логики, соответственно в ней это и будет отражено.
