Защитите свои веб-действия API от авторизованных пользователей

У меня есть такой сценарий:Защитите свои веб-действия API от авторизованных пользователей

1 Пользователь - N Project

1 проект - N Задача

1 Project - N Комментарий

Когда пользователь что он может сделать:

/api/tasks/1

, чтобы удалить его задачу, но когда он делает/api/задачи/2 он удаляет задачу кого-то другого

/api/comments/1

, чтобы получить его комментарий, но когда он делает/API/комментарии/2 он читает задачу кого-то другого

Как я могу перехватить пользователя (манипулирование URI) и проверить общий способ, чтобы пользователь мог удалить эту задачу.

Задача и комментарий ничего не знают о пользователеId, так как может запретить пользователю удалять данные других людей?

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

UPDATE ответить @A Khudairy`s вопрос

1) электронная почта + пароль отправляется апи.

2) Api возвращает пользователя с токеном пользователя.

3) Тогда при каждом запросе токен отправляется апи, (так что Iknow, которые пользователь делает то, что и справиться с этим в интерфейсе.)

источник

2014-01-16 Elisabeth

Как вы реализуете авторизацию в своем приложении –

См. Мое обновление выше. – Elisabeth

ну я бы лично не решил это с помощью URI (я не думаю, что есть безопасный способ достичь этого). Я реализую настраиваемый фильтр авторизации. Обратитесь к этому link за помощью в том, как это сделать, если вы не знакомы с ним.

В фильтре я использовал бы токен, чтобы получить идентификатор пользователя, и использовать данные маршрута, чтобы узнать, какую процедуру пытается выполнить пользователь (и идентификатор задачи или комментария), а затем принять решение, если пользователь может продолжить основываясь на этом.

Фильтры могут быть зарегистрированы тогда поверх класса контроллера или только по каким-либо методам действий или из global.asax для всех действий, если это необходимо.

источник

2014-01-16 12:12:34

В пользовательском AuthorizationFilter у меня есть доступ к инъецированным службам в ctor контроллера api? – Elisabeth

Я только подумал, что это действительно имеет смысл использовать фильтр для этой задачи. Я не могу использовать один фильтр, чтобы управлять ими всеми ... Мне нужно было бы создать несколько фильтров. Я просто думаю, что смогу это сделать частью моих бизнес-сервисов и бросить туда пользовательское исключение, пойманное в контроллере api, возвращая 403 то, что вы думаете? – Elisabeth

Это тоже имеет смысл. Что бы ни было хорошо для вас ... у нас была какая-то аналогичная проблема, и мы использовали фильтры .. но оба они в порядке, я думаю .. преимущество для фильтров, что вы вернете правильное сообщение «не авторизован» –

Звуки для меня, как вы либо будете иметь, чтобы добавить UserId для объектов Comment и Task, чтобы вы могли легко проверить или вам нужно будет убедиться, что задача или комментарий принадлежит проекту, к которому пользователь имеет доступ тоже?

Если я не понимаю ваш вопрос?

Если у задачи или комментария нет UserId, как вы собираетесь различать свои собственные комментарии и задачи и кого-то elses?

источник

2014-01-16 09:45:44 BenjaminPaul

Защитите свои веб-действия API от авторизованных пользователей

ответ

Смежные вопросы