Comments 18
Если раскрыть все спойлеры кроме тех, которые с кодом меню, которого там не должно было быть, то статья будет не такой и большой, зато не нужно лишний раз кликать, чтобы увидеть маленькую картинку., Представление из примерно 10-15 строк html превратилось в 100, что ломает сам паттерн MVC. Если хочется редактировать на лету, то можно воспользоваться тем же xml, базой данных, но не хардкодить анонимные объекты и потом ещё с помощью linq что-то выбирать, представление должно быть простым без подобной логики. По поводу двух баз данных я не понял задумку, чего уж скрывать я не очень и понимаю как будет организована вся работа с ней, в одной пользователи, в другой деньги, как целостность будет организована? связи? каскадное удаление?
Одна БД используется только для авторизации, во второй хранятся все данные — я сторонник отделять мух от мяса.
Но пока я действительно не думал, как мне в список расходов записывать логин того, кто этот расход делал.
С другой стороны, логин авторизованного пользователя у нас есть и без БД.
UFO landed and left these words here
Логичный вопрос — но учитывая специфику данного проекта — пользователь врядли будет удаляться.
Заведи модельку, которая из куков либо из того же HttpContext.Current.User будет брать роль пользователя и отдавать во вьюшку список доступных пунктов меню.
WTF? Я прямо даже не знаю, что тут хуже.

Прямое обращение к данным из представления? Логика в представлении? Прямое использование HttpContext.Current и Roles? Подключение к БД под windows-эккаунтом?
1,2,3 — Код был написан по быстрому и сейчас я думаю, как лучше этот код переписать.
4 А в чем, собственно, проблема?
Код был написан по быстрому и сейчас я думаю, как лучше этот код переписать.

А зачем показывать плохой быстро написанный код?

А в чем, собственно, проблема?

А под каким эккаунтом крутится сайт на IIS?
Я как раз взялся за разработку простенького сервиса, требующего регистрации и был крайне удивлен невозможностью кастомизации стандартного механизма аутентификации/авторизации в ASP.NET MVC.
В частности нужна поддержка пользователей через мою собственную таблицу без ролей. Также весь функционал поддержки пользователей должен работать через аякс (т.е. страница у сервиса будет всего одна).
Так вот — эта задача для меня оказалась сложнее задачи реализации основного функционала.
Думаю это может стать препятствием на пути миграции существующих проектов на ASP.NET MVC.
Вы очень плохо смотрели.
Штатный, описанный мной функционал делается за совсем смешное время, чуть больше, если писать самостоятельно.
А есть такая штука как «custom membershipprovider», например, который дает авторизацию, например по active directory, по ней куча статей
Да нормально вроде я смотрел. Единственное что нашел, это готовый каркас проекта на github (хотя он под asp.net mvc 3, но думаю подойдет).
Здесь например советуют использовать SqlMembershipProvider, что не очень то, что хотелось-бы.
был крайне удивлен невозможностью кастомизации стандартного механизма аутентификации/авторизации в ASP.NET MVC

Простите, вы какой «стандартный механизм» имеете в виду?

А то у asp.net mvc собственного механизма аутентификации нет вообще, они используют механизмы от asp.net; а те, в свою очередь, подстраиваются очень легко — можно взять Forms-аутентификацию, где вообще вся логика отдается вам, можно реализовать свой собственный membership provider, можно подключить Claims-based-аутентификацию, а в той уже либо реализовать свой собственный провайдер аутентификации или сделать свой STS. Короче, вариантов настройки дофига.

Что же касается собственного механизма asp.net mvc, то он есть только для авторизации, и он тоже настраивается гибче некуда — и локальные фильтры, задаваемые атрибутами, и глобальные фильтры, задаваемые фабрикой, и специальные методы в контроллере… тоже куча возможностей.

Думаю это может стать препятствием на пути миграции существующих проектов на ASP.NET MVC.

Миграции откуда? С WebForms? Мигрирует один-в-один, все механизмы просто сохраняюстя. Или откуда?
Вот этот.
К сожалению нету возможности изучать вопрос досконально. Есть идея и есть желание побыстрее ее реализовать.
Еще раз что не совсем тривиально (для меня во всяком случае) — реализовать кастомный (или модифицировать то, что предлагает визард) механизм аутентификации, который бы использовал одну кастомною таблицу.
Вот этот.

Если прочитать внимательно, то сразу становится видно, что он не от .mvc, а от webmatrix.

Еще раз что не совсем тривиально (для меня во всяком случае) — реализовать кастомный [...] механизм аутентификации, который бы использовал одну кастомною таблицу.

А в чем проблема? Берете Membership Provider, все ненужные методы затыкаете эксепшенами, в оставшихся, кажется, двух пишете нужный код доступа к таблице. Все. Работы часа на два, наверное. Ссылка выше.
Only those users with full accounts are able to leave comments. Log in, please.