Да-да, говорят, поставь атрибут Authorize. Но у меня есть в модели функция вывода списка (как модели) товаров, и среди прочих данных этих товаров есть ссылки, которые может видеть только авторизованный пользователь. Значит, контроллер вызывает функцию списка и она в представлении уже проверяет через if(Request.IsAuthenticated), можно ли показывать ссылки или нет. Если я ставлю Authorize на контроллер, то без авторизации пользователь уже не увидит этого списка. Если ставлю кеширование без Authorize, то даже без авторизации пользователь может видеть то, что ему не положено - т. е. if(Request.IsAuthenticated) не срабатывает, т. к. страница закеширована с true для этих проверок.

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

А как сделать с одним методом и одной моделью? И вообще, как обычно делается в таких случаях?

OracleLover

У меня ссылка на загрузку показывает не напрямую на файл, а на другой метод контроллера, который уже помечен атрибутом авторизации, так что даже зная ссылку, неавторизованный пользователь ничего не скачает. То, что неавторизованному пользователю может быть известен прямой адрес на загрузку файлов (вида "контроллер/метод/параметр") считаю нормальным - какой смысл скрывать это от него?

Я не хочу редиректить. У меня метод возвращает таблицу (или список, как я раньше сказал), у которой один столбец - ссылки, доступные только авторизованным пользователям. Я хочу, чтобы один и тот же метод возвращал такую таблицу. Но вот проверки на авторизацию, где бы они ни стояли (вьюха, метод модели, метод контроллера), уже закешированы, т. к. атрибут кеширования у меня на методе контроллера применён. С атрибутом Authorise кеширование нормально работает, а с проверками Request.IsAuthenticated - не работает. Самое первое, что приходит на ум - сделать два метода контроллера: один с атрибутом авторизации для зареганных пользователей, а второй - без для незареганных. Причём на каждый свой кеш должен быть. Но это дублирование кода и вообще выглядит топорным.

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

OracleLoverИ если неавторизован - то редиректить к примеру на страницу LogOn(по-умолчанию итак туда и редиректит).
user7320Я не хочу редиректить.
Я имею ввиду, что описанный вами подход с перенаправлением у меня в другом месте применяется - для всяких личных страниц, смен пароля и прочих. А тут общий метод, который показывает почти одно и то же (т. е. почти одинаковый код для авторизованного и неавторизованного пользователей).

Вот тут http://stackoverflow.com/questions/2526509/request-isauthenticated-problem-with-cache-in-asp-net
в конце рекомендуют сделать две разные страницы (и, как я понял, два разных метода контроллера) для авторизованного и неавторизованного пользователей. Разве это верный подход? Фактически, предлагается делать на одно по сути действие столько перегрузок методов, сколько ролей в вашем приложении определено. А не слишком ли запутанно?

Далее, там же выше предлагается как-то (я не понял, как конкретно) использовать VaryByCustomString метод. Этот метод у меня уже используется для смены культуры для интернационализации моего приложения. Т. е. он уже занят.


Как поступить-то?

У меня такое ощущение, что я задал вопрос из разряда "сколько будет дважды два?" и никто просто не хочет отвечать на тако детский лепет. Ну или ситуация настолько специфична, что никто никогда не делал у себя кешированных сайтов с авторизацией на MVC. Ау, народ, кто как делал-то? :))