Отложенная регистрация на функционале ASP.NET профилей.
MS оснастила ASP.NET удивительными сервисами, некоторые из которых удается применить на практике с огромным трудом. В этой заметке я опишу, как именно мне удается применять на практике казалось бы совершенно нелепые микрософтовские сервисы.
Речь пойдет о встроенном в ASP.NET механизме аутентификации (регистрации пользователей, проще говоря) и авторизации (фактически применения для этого встроенного в ASP.NET функционала профилей). Как устанавливается микрософтовская база - описано в одной из моих ранних заметок в этом разделе - но здесь я расскажу немного о другом подходе.
В практике значительное количество сайтов не выделяет отдельно логин, а отдельно почту (как это считает мейн-стримом MS), а полагает, что логин - это и есть собственно почтовый адрес. В принципе - это разумно, тк не позволяет 'левому' пользователю ввести в качестве своей почты - почту 'правильного' пользователя и таким образом заблокировать 'правильному' пользователю вход на сайт. MS как всегда слона-то и не приметила и вовсе не предусмотрела каких-бы то ни было вариантов блокирования этой ситуации в своем движке.
Это первое, что мы рассмотрим в этой заметке. Это функционал я называю - ОТЛОЖЕННАЯ РЕГИСТРАЦИЯ.
Иными словами, зарегистрировавшись, юзер продолжает размещать свой контент на сайте, но видимым другим он станет только после активации логина с указанного почтового адреса. Именно это не позволяет 'левым' юзерам блокировать доступ 'правильных' юзеров на сайты.
Как же делается такой функционал? Для этого необходимо сделать несколько шагов. Во-первых, как всегда, у MS ничего не бывает без багов. И если вы попробуете в лоб из букварика применить микрософтовскую базу юзеров в своем проекте, у вас ничего хорошего не получится. Юзера будут ДВОИТСЯ. Те один юзверь с одним гуид-ом будет создаваться для имени приложения '/', а другой юзверь с тем же логином - для имени приложения '/votpusk' (в моем случае).
Как микрософтовцы пропустили такой элементарный баг - науке это неизвестно, зато пытливый ум пользователей 'пиридавых' технологий выработал рецепт борьбы с этим багом. Для этого надо явно указать имя приложения во всех трех секциях конфига - roleManager, membership, profile. В итоге фрагмент с багом обходится и встроенным в ASP.NET сервисом аутентификации юзеров все-таки воспользоватся удается. А интересующий нас фрагмент конфига будет выглядеть вот так. Собственно говоря, тут идет речь о строках 80-97. Именно они предназначены для устранения указанного бага.
Теперь еще пару каментов указанного конфига. База пользователей размещается там, куда смотрит 57-я строка. На нее же ссылается 84, 90 и 96-я строка (в которой нам и пришлось явно поименовать имя приложения). А вот строки 99-102 описывают собственно местонахождение в базе полей, которые нам необходимы для реализации функционала отложенной регистрации. Строки 35-49 - это управление описываемым функционалом отложенной регистрации. Ну а строки профиля 104-138 тут приведены пока справочно, в последней части моей заметки мы поговорим о профиле подробнее и обсудим тот гиморой, который нам создала MS своей убогой реализацией функционала профиля.
Прежде всего, хотелось бы попытатся воспользоватся в проекте встроенными в ASP.NET AU-контролами от MS. Однако применить их в лоб тоже не удастся. Причина проста - основной управлящий пераметр этого контрола - ReturnURL почему-то сделан достпуным только по чтению. Однако пытливый ум может после продолжительного размышления придумать как применить на практике это микрософтовское чудо. Оказывается в нем есть событие Authenticate, и в нем-то возможно управлять парметром ReturnURL. Итого, наша первая форма залогинивания будет выглядеть вот так.
Ну а тот самый изменяемый для каждого юзера класс - он определяется из класса-перечислителя всех основных страничек кабинета юзера, фрагмент которого выглядит вот так. Как видите, тут я не применял особых хитростей - ГУИД юзверя во встроенной микрософтовской базе - он и является первым GET-параметром по страничкам этого сайта.
Теперь ближе к регистрации. Сама по себе форма регистрации стандартна. Как видите, я делаю их из двух фрагментов, чтобы залогиненный юзер, попав на нее - мог сразу же разлогинится. Кому интересно, посмотрите как блокирутся клиентским кодом постбек (и как серверной привязкой правильно формируется клиентский код). Код формы тоже бесхитростный, однако обратите внимание, что я активно пользуюсь микрософтовским функционалом профилей - и напрямую сохраняю факт активированности логина - в профиль юзверю.
Я пользуюсь функционалом профилей исключительно из-за его удобства - тк среда ASP2 автоматически создавала класс-обертку, что позволяло пользоватся свойствами профиля в коде типизированным образом. Никак не могу обьяснить этой подлости MS, но почему-то этот немногочисленный и рабоспособный функционал из VS2005 почему-то MS отказалась поддерживать и, лишив нас этих привычных удобств - MS кастрировала VS2005 именно в этой части - http://msdn.microsoft.com/en-us/library/aa983476.aspx : The Visual Studio 2008 Web application project does not automatically include the ProfileCommon class.
Возвращаясь к коду формы - обратите внимание, что за функционал отложенной регистрации отвечают строки 41-45 формы.
00040: 'отложенная активация 00041: Dim ActivateGUID As Guid = Guid.NewGuid 00042: Dim ClearDate As DateTime = Now.AddHours(Double.Parse(System.Configuration.ConfigurationManager.AppSettings("LoginClear"))) 00043: MyTypedProfile.LoginClearDate = ClearDate 00044: MyTypedProfile.LoginIsActivate = False 00045: MyTypedProfile.LoginActivateGUID = ActivateGUID.ToString
Сама по себе форма активации юзера, куда попадает юзер, щелкнув по ссылке, которая ему пришла почтой, тоже совершенно бесхитростна - и просто проверив сгенеренные ГУИДЫ, хранимые в базе с пришедшими в реквесте - проставляет указанный флажок активированности профиля.
Теперь посмотрим, как я делаю на пользовательских формах, чтобы юзер мог размещать свою информацию, но кроме него ее никто не видел. Тут прежде всего архитектурный вопрос. Большиство страниц этого моего сайта - унаследовано от базовой странички, которая расширяет стандартный класс PAGE несколькими полезными свойствами, которые нужны мне на каждой страничке. Соответственно, каждая страничка сайта содержит один вот такой такой фрагмент, с пустым текстовым контролом.
Теперь рассмотрим более интересный момент. Как организовать чистку просроченных логинов? О, тут широкий выбор возможностей. Но мой выбор - это множество задач, ответвленных от главной задачи приложения в GLOBAL.ASAX. Эту технику я освоил давно и применяю ее с успехом, даже с учетом рестарта приложений. Фишка тут в том, чтобы при рестарте все сохранялось в базе. Те залача стартанула - отработала - и ее результат не в пямяти, а в базе. Так рестарт будет не страшен.
Небольшой фрагмент моего стартового файлика вы можете увидеть тут. Собственно стартер этой задачи находится в строках 118-120. Он управляется параметрами, прописанными в конфиге. Кстати обратите внимание на мою технику защиты от взлома сайта и назначение того самого неудаляемого админа, который производит назначение всех прочих админов. Раньше я делал не так, но теперь нашел это решение. Эти проблемы опять же связаны с енприспособленностью ASP.NET для практической работы - никак не продумано, тут как на удаленном хостинге запустить эту приблуду - причем как правило к удаленному хостингу можно ведь коннектится только локальным сайтом. Вот и возникает вопрос как в той удаленной базе прописать того самого первого админа, который раздаст права всем остальным.
Ну и в заключение этой небольшой описанной мною фишки - отложенной регистрации - я опишу свою последнюю форму, которая тоже входит в этот комплект - но уже в состав CMS. Она позволяет активировать логины без мыла, например если вы заметили выше - у меня есть замечательные активированные логины типа 3@3.3 - они активированы именно этой формой.
Вообще я с профилем работаю весьма активно, причем во многих своих проектах, и даже храню в них бинарники. В том числе описанный выше функционал отложенной регистрации тоже, как видите, полностью построен на встроенной микрософтовской базе и профилях юзеров. И самое время нам тут вникнуть в профиль немного подробнее и асилить главную тупость MS во всем ее профильном подходе - и главное препятствие использования ее профилей на практике.
Так вот, основная ограниченность микрософтовского API профилей в том, что он не позволяет взять данные профиля на уровне SQL.
)
|
|