В принципі можливо будувати сайти взагалі без будь-якої аутентифікації. Просто вписую користувачеві в Куку наприклад номер замовлення або будь-яку персоніфіковану настройку. Відповідно, коли браузер в об'єкті Request приносить Куку, можна відразу позиціонувати клієнта на його замовлення та налаштування. Це досить рідко застосовуваний підхід, однак мені вдалося реалізувати саме такий підхід в реально працюючому електронному магазині.
Але для того щоб працювати з підтримкою аутентифікації і персоналізації, захистом в ASP2, треба виконати ряд попередніх налаштувань:
У нас вийшло не що інше як той самий контрол LOGIN, тільки зроблений самостійно. І тут ми бачимо ще два важливих класи в системі аутентифікації ASP2 з простору імен System.Web.Security. Клас FormsAuthentication є фактично програмне уявлення тега FORMS з конфігурації і має метод для входу власне в сайт. А клас Membership - це той самий клас маніпулювання користувачами в базі (до якого ми зверталися через Web Site Administration Tool). В тому числі, звертаючись до алгоритмів SHA1, цей клас проводить перевірку пароля. Насправді - клас Membership - це оболонка, яка звертається до класу MembershipProvider. Поглянувши на Web Site Administration Tool ми побачимо все три вбудованих провайдера. Свій провайдер створюється за допомогою перевизначення базових методів стандартного провайдера. І хоча це досить поширена техніка, тут я її розглядати не буду.
Цікаво, що хост-процес девелоперського сервера студії завжди повертає імперсоналізірованний контекст (на відміну від контексту IIS, розглянутого вище), саме тому ми зазвичай спостерігаємо при першому запуску програми під IIS таку картинку.
На закінчення я опишу спосіб вирішення однієї невеликої проблемки, що виникає при використанні стандартних конфігураційних баз ASP2. Справа в тому, що при проектуванні сайту ВЕСЬМА ЗРУЧНО працювати на підставі ролей. Наприклад, перевіряти приналежність до тієї чи іншої ролі в CMS. Або, як було показано - міняти меню сайту в залежності від ролі, до якої належить користувач. Але.
Цей простий сайт буде складатися з ОДНІЄЇ сторінки і розгортається адміном замовника в будь-який з підкаталогів CMS. У нього дуже простий CONFIG, який треба буде пріконнектіть до конфігурується базі:
І така ж проста, але важлива сторінка
На закінчення хотілося б відзначити, що аутентифікаційні бази і бази профілів зроблені непогано і вельми корисні. Як зберігати в них довільні бінарні файли - я розповів тут.