Я хотел бы просто проверить из контроллера, авторизован ли другой URL-адрес.
Так, например, я бы хотел вызвать контроллер таким образом:
[HttpPost]
public ActionResult IsUrlAuthorized(string url)
{
bool isAuthorized = // What do I put here?
return Json(isAuthorized);
}
Поэтому я хотел бы знать, что я мог бы позвонить, чтобы проверить, авторизован ли текущий пользователь для переданного URL или нет.Я предполагаю, что ответ как-то связан с маршрутами, которые находятся немного за пределами MVC?
Это несколько схожий вопрос, но не совсем то же самое: ASP.NET MVC.Проверьте, авторизован ли пользователь из JavaScript
Так как пользователь может иметь или не иметь общих полномочий, но может не иметь прав или назначений ролей для просмотра определенного URL.
Идеи?
Обновление: я использую стандартные атрибуты авторизации MVC для блокировки моего приложения, поэтому я просто приведу пример того, как это выглядит здесь.В MVC Маршруты отображаются в Контроллеры.Один метод на контроллере может быть ограничен одной или несколькими ролями:
public class HomeController : Controller
{
[Authorize(Roles = "User, Moderator")]
public ActionResult ListRecentPosts()
{
. . .
}
}
Или весь контроллер может быть ограничен одной или несколькими ролями:
[Authorize(Roles = "Admin")]
public class AdminController : Controller
. . .
Фактический URLчто любой из этих методов контроллера реагирует на сопоставление по умолчанию в стандартном приложении MVC:
routes.MapRoute("Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);
Но вы можете быть милыми с вашими пользователями и делать URL-адреса предположительными, добавляя гораздо больше маршрутов - какВ результате метод Controller может иметь много имен, указывающих на него.Вы не можете просто предполагать и выводить имя контроллера из URL (даже если он отображает таким образом половину URL на сайте).
Так что, по-видимому, мне либо нужен способ напрямую запросить механизм маршрутизацииавторизован ли URL-адрес для текущего пользователя или двухэтапный запрос механизма маршрутизации для какого контроллера и метода, а затем спросите, авторизованы ли они, - надеюсь, не с помощью отражения и сопоставления ролей напрямую, как это снова может показатьсямного.
Обновление 2: способ, которым это пришло, состоит в том, что у меня есть полоса учетной записи в верхней части моего приложения.Его состояние может измениться, выбрав одну из нескольких учетных записей, для которых вы авторизованы.В зависимости от того, где вы находитесь в приложении, выбранная вами учетная запись может иметь полномочия для просмотра этой страницы - и вы можете быть в процессе заполнения формы, которую не хотите потерять.Таким образом, наивный подход - просто обновить, когда они выбирают другую учетную запись - вреден, и тратит время пользователя, даже если нет формы, и они просто читают страницу, которая полностью текстовая.
Хотя это удобстводля пользователя это хорошо, пользователь собирается честно предположить, что страницы, которые он не может видеть как пользователь, у которого не должно быть разрешения, действительно запрещены (и было бы вредно оставлять их на запрещенной странице - предпринятые действияот этого не получится).Поэтому мне нужно знать, следует ли перенаправлять их на основании их новых разрешений.
Одна из вещей, которые мне нравятся в .Net, - это то, как многие из его лучших библиотек так хорошо разлагаются, что вы можете легко перекомпоновывать вещи, которыечасть его нормальной функциональности или новый поворот.Как модуль маршрутизации, так и MVC выглядят очень хорошо сконструированными, поэтому я должен подозревать, что это можно сделать.
Дешевый взлом - убедиться, что мой модуль авторизации возвращает непротиворечивый код состояния перенаправления, когда пользователь не 't авторизован, и когда пользователь меняет свою учетную запись в полосе учетных записей, запускает 2 вызова AJAX: один для изменения учетной записи, а затем второй для текущей страницы через AJAX просто для проверки кода состояния HTTP.200 OK означает оставить страницу как есть, Redirect означает следовать перенаправлению.Очевидно, что это немного уродливо, включает дополнительный HTTP-вызов, создает ложное попадание в журналы и делает предположение о том, как обрабатывается авторизация в приложении.
Может быть вторичная проблема - страница может быть авторизована, но просто измените, как она работает или выглядит. Это конкретное приложение не изменяет внешний вид в зависимости от учетной записи (кроме самой учетной записи), и я могу обрабатывать изменения функциональности, просто предоставляя настраиваемое событие, которое формирует прослушивание - они могут перезагрузить любые соответствующие данные с сервера в ответ на него.