Привязка параметров действия для запроса куки в ASP.NET MVC - что случилось? - PullRequest
4 голосов
/ 23 февраля 2009

В нескольких ранних предварительных версиях ASP.NET MVC аргументы методов контроллера могли бы быть разрешены путем проверки строки запроса, затем формы, затем файлов cookie и наборов серверных переменных, как описано в этой публикации от Стивена Вальтера .

Например, этот код работал:

public class MyController : Controller {

    // This should bind to Request.Cookies["userId"].Value
    public ActionResult Welcome(int userId) {

        WebUser wu = WebUser.Load(userId);
        ViewData["greeting"] = "Welcome, " + wu.Name;
        return(View());
    }
}

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

Было ли это изменение отражено в примечаниях к выпуску? Если это изменение в платформе, есть ли рекомендуемая альтернатива для привязки файлов cookie и серверных переменных таким способом?

РЕДАКТИРОВАТЬ: Спасибо тем из вас, кто ответил до сих пор. Возможно, я выбрал плохой пример, чтобы продемонстрировать это; наш код использует файлы cookie для различных форм «удобного», но не обязательного сохранения (запоминание порядка результатов поиска и тому подобное), поэтому это ни в коем случае не является чисто проблемой аутентификации. Последствия для безопасности использования пользовательских файлов cookie хорошо документированы; Меня больше интересуют текущие рекомендации по гибким, легко тестируемым методам получения значений cookie. (Как я уверен, вы можете оценить, приведенный выше пример может иметь последствия для безопасности, но его очень, очень легко проверить!)

Ответы [ 3 ]

3 голосов
/ 03 марта 2009

Я не верю, что куки больше проверяются, и я не уверен, является ли это преднамеренным или нет.

В приложении против RC, которое я написал недавно, я использовал код CookieContainer из этого поста и пользовательский атрибут авторизации для таких классов:

public class LoginRequiredAttribute : AuthorizeAttribute
{
    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        IAppCookies a = new AppCookies(new CookieContainer());
        return a.UserId != null; /* Better checks here */
    }
}

В моем AppCookies.cs просто есть метод для UserId, подобный этому (для вас автоматически разрешается int / null):

public int? UserId
{
    get { return _cookieContainer.GetValue<int?>("UserId"); }
    set { _cookieContainer.SetValue("UserId", value, DateTime.Now.AddDays(10)); }
}

Затем просто убедитесь, что ваш web.config настроен так, чтобы он указывал на вашу страницу входа в систему следующим образом:

<authentication mode="Forms">
<forms loginUrl="~/Login"/>
</authentication>

Это означает, что в моем контроллере для получения идентификатора пользователя мне нужно сделать что-то вроде этого, чтобы получить мой cookie:

[LoginRequiredAttribute]
public class RandomController : Controller
{
    BaseDataContext dbContext = new BaseDataContext();
    private readonly IAppCookies _cookies = new AppCookies(new CookieContainer());

    public ActionResult Index()
    {
        return View(new RandomViewData(dbContext, _cookies.UserId));
    }
}
3 голосов
/ 05 марта 2009

Я полагаю, что именно последствия для безопасности убедили их убрать их:

Комментарии в сообщении Стивена Вальтера ASP.NET MVC Совет 15 , приведший к публикации Фила Хаака Пользовательский ввод в овечьей шкуре , особенно его комментарий здесь :

@ Трой - Первый шаг - сначала отговорить разработчиков от этого мышления. ;) Шаг первый простой (параллельно) для нас, чтобы исключить возможность этого мышления в этом случае.

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

В сочетании со сложностями, связанными с вызовом этих методов из различных классов построителей действий.

Кажется, я не могу найти какую-либо явную документацию о контроллерах, которые ведут себя так же, как пост Стивена, поэтому я думаю, что он был "тихо отброшен".

0 голосов
/ 02 марта 2009

Помимо очевидных последствий для безопасности , зачем вам в любом случае передавать cookie на маршруте?

Конечно, вам лучше иметь атрибут Authorize в действии, указывающий, что пользователь должен пройти аутентификацию перед выполнением действия.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...