При этом среда ASP.NET не может отличить обратный вызов, например при нажатии кнопки на web-страницы, от обновления. Иногда такое поведение может нарушить логику работы программы и исказить данные.

Например, в разработанном web-приложении покупатель может удалять товары из покупательской корзины, при этом он ставит галочку напротив этого товара и нажимает кнопку удалить. В обработчике этой кнопки определяется номер строки в GridView, где отмечена галочка на удаление, и товар удаляется из корзины. После этого страница отправляется обратно пользователю. Если теперь будет нажата кнопка "Обновить" на панели браузера, то будет повторён предыдущий запрос и, соответственно будет удалена ещё один товар. Таким образом, при обновлении страницы после операции удаления существует вероятность удалить ещё одну товар. Естественно, что такое поведение недопустимо. Для того чтобы обойти исправить такое поведение, необходимо отличать обновление страницы от обратной отсылки после нажатия кнопки.

Для этого используется новый класс web-страницы RefreshPage, унаследованный от класса System. Web.UI. Page, в котором добавлена возможность распознавания обновления. Для этого используется HTTP-модуль, осуществляющий предварительную обработку страницы. Далее рассмотрен алгоритм распознавания обновления страницы.

Для каждого запроса, обслуживаемого в контексте сеанса, выдается уникальный и возрастающий номер. Страница ASP.NET создает билет непосредственно перед созданием ответа и сохраняет его в специальном скрытом поле, которое передаётся в браузер. Когда пользователь передает новый запрос скрытое поле (если оно существует) автоматически добавляется к запросу на сервер.

На веб-сервере новый HTTP-модуль проверки перехватывает событие AcquireSessionState (этот метод вызывается перед тем, как для клиента будет получена информация, специфичная для сеанса, использована для заполнения коллекции Session), получает текущий билет из скрытого поля, а затем сравнивает его с кэшированным последним выданным билетом. Последний выданный билет сохраняется в состоянии сеанса. Если номер текущего билета больше, чем последний выданный номер, или оба они равны нулю, то это обычный запроc. Больше модуль проверки обновления не выполняет никаких действий и пропускает запросы в неизмененном виде.

Если последний выданный билет больше или равен текущему билету, то запрос определяется как обновление страницы. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. Срок жизни этих данных совпадает со сроком запроса; поэтому любые данные удаляются при создании ответа. Используя статическое свойство HttpContext. Current можно получить доступ к контексту обрабатываемого запроса из любого класса, вовлеченного в этот процесс.

Http-модуль проверки обновления создает новую запись IsPageRefreshed в коллекции Items. Эта логическая переменная обозначает, запрашивалась ли страница с помощью обычного запроса или с помощью обновления. В следующем примере показана реализация http-модуля проверки обновления:

public class RefreshModule: IHttpModule

{

public void Init (HttpApplication app)

{

app. AcquireRequestState += new EventHandler(OnAcquireRequestState);

}

private void OnAcquireRequestState (object sender, EventArgs e)

{

HttpApplication app = (HttpApplication) sender;

………………………….

// Проверить на обновление

RefreshAction. Check(ctx);

return;

}

Класс RefreshAction содержит логику, определяющую, является ли текущий запрос обновлением страницы. Если он распознаётся как обновление, то в коллекции Items объекта HttpContext появляется новая запись IsPageRefreshed, которой присваивается значение true.

public static void Check (HttpContext ctx)

{

EnsureRefreshTicket(ctx);

// Получение предыдущего номера из объекта Session

int lastTicket = GetLastRefreshTicket(ctx);

…………………………………………………….

int thisTicket = GetCurrentRefreshTicket(ctx);

// Сравнение номеров

if (thisTicket > lastTicket || (thisTicket==lastTicket && thisTicket==0))

{

UpdateLastRefreshTicket (ctx, thisTicket);

………………………………………….

}

else

{

ctx. Items[PageRefreshEntry] = true;

}

Класс RefreshPage содержит свойство IsPageRefresh:

public bool IsPageRefresh

{

get {

object o = HttpContext. Current. Items [RefreshAction. PageRefreshEntry];

if (o == null)

{

return false;

}

return (bool) o;

}

Наследую класс web-страниц от класса RefreshPage можно использовать это свойство и определять обновление страницы. Таким образом, можно отслеживать обновление web-страницы при удалении товаров из покупательской корзины. Соответственно, если обнаружено обновление страницы, то товар не удаляется. Код обработчика представлен ниже:

protected void UpdateButton_Click (object sender, EventArgs e)

{

if (! IsPageRefresh && IsValid)

{

int numDeleted = 0;

…………………………………………………………………

{

if (((CheckBox) (row. FindControl ("DeleteCheck"))).Checked)

{

Profile. Cart. RemoveAt (row. RowIndex - numDeleted);

……………….

continue;

}

string regular = "[^0-9]";

string text = ((TextBox) (row. FindControl ("TextBoxQuantity"))).Text;

MatchCollection collect = Regex. Matches (text, regular);

if ((collect. Count!= 0) || (text. Length == 0))

{

continue;

}

Profile. Cart [row. RowIndex - numDeleted].Quantity = Convert. ToInt32 (((TextBox) (row. FindControl ("TextBoxQuantity"))).Text);

}

Profile. Save();

Session ["IsUpdateCart"] = true;

}

Диаграмма классов, используемых для отслеживания обновления web-страниц, приведена на рисунке 10.

Рис. 10 "Диаграмма классов, используемых для отслеживания обновления web-страниц"

4.5 Аутентификация и авторизация пользователей

4.5.1 Описание и настройка интерфейса Membership API

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

Аутентификация - это процесс определения личности пользователя.

Авторизация - это процесс определения прав и ограничений, назначенных аутентифицированному пользователю. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. В данном пункте рассмотрен интерфейс Membership API и его применение при разработке дипломного проекта. Интерфейс Roles API описан в пункте 4.5.3.

Интерфейс Membership API предоставляет полный набор функций для хранения информации о пользователях и управления ею.

При разработке дипломного проекта использовались следующие классы, предоставляемые интерфейсом Membership API:

· Membership - предоставляет методы для управления пользователями;

· MembershipUser - предоставляет отдельного пользователя, записанного в хранилище данных. Этот объект содержит всю информацию о данном пользователе и возвращается несколькими методами класса Membership;

Также Membership API содержит набор элементов управления безопасность, предназначенных для создания web-страниц регистрации, входа в систему, смены и восстановления пароля. Все эти элементы полностью настраиваемы и расширяемы. По умолчанию каждый элемент работает на основе Membership API и аутентификации форм, но при необходимости любые события можно переопределить. Аутентификация форм рассмотрена в пункте 4.5.2.

Для того чтобы использовать интерфейс Membership API необходимо создать хранилище данных и настроить его на работу с ним. Для хранения удостоверений пользователей в базе данных web-приложения с помощью программы aspnet_regsql.exe, поставляющейся вместе с.NET Framework 2.0, были созданы специальные таблицы: aspnet_Membership, aspnet_Users и aspnet_Applications, а также хранимые процедуры для доступа к ним. Далее необходимо настроить поставщик Membership API, для обеспечения доступа к хранилищу данных. Это делается с помощью файла конфигурации web-приложения web.config:

<add name= "MyMembershipProvider"

type= "System. Web. Security. SqlMembershipProvider"

………………………………………….

applicationName="/MusicInternetShop"

enablePasswordRetrieval= "true"

enablePasswordReset= "true"

maxInvalidPasswordAttempts= "5"

………………………………….

requiresUniqueEmail= "true"

passwordFormat= "Clear"

minRequiredPasswordLength= "7"/>

</providers>

</membership>

В элементе <membership><providers> определены следующие параметры настройки поставщика Membership:

· name - имя поставщика;

· applicationName - имя приложения, для которого поставщик управляет пользователями;

· type - тип поставщика. Выбирается в зависимости от используемого хранилища данных;

· connectionStringName - имя строки подключения к хранилищу данных. В данном случае используется строка поключения, описанная в элементе <connectionStrings>

· enablePasswordRetrieval - когда установлено в true, позволяет извлекать пароль из объекта MembershipUser;

· enablePasswordReset - когда установлено в true, включает функциональность для переустановки пользовательских паролей;

· maxInvalidPasswordAttempts - задаёт максимальное количество неудачных попыток входа в систему, прежде чем пользователь будет заблокирован;

· requiresQuestionAndAnswer - когда установлено в true, включает функциональность для восстановления забытого пароля используя контрольный вопрос и ответ, заданные при регистрации пользователя. Восстановленный пароль отправляется на почтовый ящик пользователя, указанный при регистрации;

· requiresUniqueEmail - указывает, должны ли адреса электронной почты быть уникальными для каждого пользователя webприложения;

· passwordFormat

После этого в web-приложении могут использоваться функции, предоставляемые Membership API. В следующем пункте подробно описана система аутентификации форм, основанная на интерфейсе Membership API, которая применяется в разработанном web-приложении.

4.5.2 Аутентификация форм

После того как соответствующим образом настроен интерфейс Membership API, можно реализовывать механизмы аутентификации и авторизации пользователей. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. ASP.NET обрабатывает cookie-набор и устанавливает контекст безопасности каждого запроса.

Аутентификация форм основана на мандатах. Это означает, что когда пользователь регистрируется, он получает так называемый мандат с базовой информацией о себе. Информация сохраняется в зашифрованном cookie-наборе, который прикрепляется к ответу, так что автоматически подтверждается при каждом последующем запросе.

Когда пользователь запрашивает web-страницу, недоступную анонимным пользователям, исполняющая система ASP.NET проверяет, доступен ли аутентифицирующий мандат формы. Если нет, то выполняется автоматическая переадресация на страницу входа в систему. На этой странице пользователь может ввести своё имя и пароль или перейти на страницу регистрации. Если пользователь успешно прошёл проверку, то исполняющая система ASP.NET автоматически устанавливает аутентифицирующий cookie-набор и переадресует пользователя на запрошенную страницу.

Как уже было сказано выше, аутентификация форм работает совместно с интерфейсом Membership API, это означает, что для создания страниц входа в систему и регистрации, можно использовать элементы управления безопасностью, такие как:

· Login - отображает текстовые поля имени пользователя и пароля, а также кнопку "Вход". Автоматически проверяет пользователя с помощью поставщика Membership;

· CreateUserWizard - в данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении;

Однако для того чтобы аутентификация форм работала необходимо настроить её в файле web.config. Ниже представлена настройка системы аутентификации форм для разработанного web-приложения:

<forms name= "CookieName"

loginUrl= "Login.aspx"

……………………….

slidingExpiration= "true"

cookieless= "AutoDetect"

protection= "All"

……………….

path="/">

</forms>

</authentication>

В элементе <authentication> определены следующие параметры настройки:

· mode - указывает тип используемой аутентификации. Помимо аутентификации форм, существует windows-аутенификация, использующая для проверки учётные записи пользователей Windows;

· name - имя cookie-набора;

· loginUrl - определяет на какую страницу должен быть перенаправлен пользователь, чтобы войти в систему;

· timeout - период времени в минутах действительности cookie-набора. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. Если же они будут устаревать редко, то возникнет опасность их хищения и нерегламентированного использования;

· slidingExpiration - включает и отключает скользящее устаревание cookie-наборов. При включении устаревание cookie-наборов будет сбрасываться при каждом запросе страницы пользователем, то есть каждый запрос будет продлевать время жизни cookie-набора;

· cookieless - позволяет указать, где будут храниться мандаты аутентификации форм. Возможные значения UseCookie, UseUrl и AutoDetect. Использование cookie-набора требует, чтобы их использование поддерживал браузер клиента. В данном случае используется значение AutoDetect, устанавливающая применение cookie-наборов, если браузер клиента их поддерживает. В противном случае исполняющая система ASP.NET кодирует мандат аутентификации форм в запрошенный URL;

· protection - в данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении;

· defaultUrl - если пользователь был перенаправлен на страницу входа в систему с другой страницы web-приложения, то после успешного входа в систему он будет перенаправлен на запрошённую страницу. Однако, если пользователь сразу запросил страницу входа в систему, то после успешной аутентификации он будет направлен на страницу, указанную в этом параметре;

Система аутентификации позволяет отличить анонимных пользователей от аутентифицированных. Таким образом, мы можем закрыть доступ к определённым web-страницам и каталогам для анонимных пользователей. Чтобы это сделать необходимо в файле web.config в элементе <authorization> указать <deny users="?" />. Однако если аутентифицированные пользователи должны иметь разные уровни доступа к страницам, то необходимо как-то различать их. Для этого используется система авторизации и интерфейс Roles API, которые будут рассмотрены в следующем пункте. Также будет описано, как с помощью файла web.config открывать и закрывать доступ к разным каталогам и страницам приложения для разных групп аутентифицированных пользователей.

4.5.3 Авторизация и настройка интерфейса Roles API

Как уже было сказано в пункте 4.5.1, авторизацией называется процесс определения прав и ограничений, назначенных аутентифицированному пользователю. Другими словами, это процесс определения того, имеет ли аутентифицированный пользователь достаточные привилегии на выполнение того или иного действия. Таким действием может быть запрос web-страницы, доступ к ресурсу или выполнение специфичных для приложения задач.

Для того чтобы разграничить доступ разных пользователей к разным группам страниц web-приложения используется механизм ролей. Назначая права или ограничения для роли, мы тем самым назначаем их для каждого пользователя относящегося к этой роли. В разработанном web-приложении предусмотрено две роли:

· Users - к этой роли относятся покупатели музыкального Интернет-магазина. Когда покупатель регистрируется в Интернет-магазине, использую страницу регистрации, он автоматически приписывается к роли Users. Пользователи из группы Users имеют доступ ко всем общедоступным страницам, а также к страницам из подкаталога ProtectedPages. Описание этих web-страниц и их назначение приведено в пункте 4.1.1.

· Administrators - к этой роли относятся администраторы музыкального Интернет-магазина. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. Описание этих web-страниц и их назначение приведено в пункте 4.1.1.

Права доступа для каталогов указываются декларативно в файле web.config. Специальный HTTP-модуль UrlAutorizationModule просматривает эти правила и проверяет каждый запрос, чтобы гарантировать, что пользователю не будет доступен ресурс, доступ к которому для него закрыт. Авторизация этого типа называется авторизацией URL, потому что рассматривает только две детали - контекст безопасности пользователя и URL-ресурса, к которому пользователь пытается обратиться. Если доступ к странице запрещён, то пользователь будет перенаправлен на страницу входа в систему.

Правила авторизации указываются в элементе <authorization> файла web.config. Существует два типа правил: разрешить (allow) и запретить (deny).

В файле web.config разработанного web-приложения определены следующие правила авторизации:

1. Для всех web-страниц из корневого каталога открыт доступ для любого пользователя.

</authorization>

2. Ко всем web-страницам из подкаталога ProtectedPages доступ для не аутентифицированных пользователей, а также пользователей роли Administrators закрыт. К ним имеют доступ только пользователи, относящиеся к роли Users.

<system.web>

…………………

……………………

</system.web>

</location>

3. Ко всем web-страницам из подкаталога AdminProtectedPages доступ для не аутентифицированных пользователей, а также пользователей роли Users закрыт. К ним имеют доступ только пользователи, относящиеся к роли Administrators.

<system.web>

…………………….

</authorization>

……………….

</location>

Для того чтобы обеспечить работу механизма авторизации на основе ролей необходимо настроить интерфейс Roles API. Как и в случае с Membership API с помощью программы aspnet_regsql.exe в базе данных были созданы таблицы aspnet_Roles и aspnet_UsersInRoles, а также хранимые процедуры. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении.

После того как в базе данных созданы необходимые таблицы и хранимые, нужно сконфигурировать интерфейс Roles API и поставщик Roles в файле web.config. Для разработанного web-приложения настройка выглядит следующим образом:

<roleManager

defaultProvider= "MySqlProvider"

cacheRolesInCookie= "true"

cookieName=".MyRoleCookie"

cookieTimeout= "20"

……………………

cookieSlidingExpiration= "true"

cookieProtection= "All"

createPersistentCookie= "false">

…………………………….

type= "System. Web. Security. SqlRoleProvider"

connectionStringName= "connStr"

applicationName="/MusicInternetShop"/>

</providers>

</roleManager>

В элементе <roleManager> определены следующие параметры настройки, многие из которых аналогичны, описанным в пункте 4.5.2:

· defaultProvider - указывает имя поставщика, используемого по;

· cacheRolesInCookie - если установлено в true, устанавливает сохранение информации о роли в cookie-наборе, вместо постоянного чтения информации о;

· cookieName - имя cookie-набора;

· cookieTimeout - время устаревания cookie-набора. Подробнее описано в пункте 4.5.2;

· cookieSlidingExpiration - включает и отключает скользящее устаревание cookie-наборов. Подробнее описано в пункте 4.5.2;

· cookieProtection - указывает уровень безопасности cookie-наборов. Подробнее описано в пункте 4.5.2;

· createPersistentCookie - если установлено в true, cookie-набор постоянно сохраняется на клиентской машине, иначе он существует только в течении сеанса и удаляется, когда пользователь закрывает браузер;

В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении.

В пунктах 4.5.1, 4.5.2 и 4.5.3 и были рассмотрены интерфейсы Membership API и Roles API, которые применялись для создание системы аутентификации и авторизации пользователей в разработанном web-приложении. На рисунке 11 представлена общая схема аутентификации и авторизации пользователей.

131

Рис. 11 "Схема аутентификации и авторизации пользователей"

4.6 Описание профилей пользователей

Системы аутентификации и авторизации позволяют различать покупателей музыкального Интернет-магазина и разграничивать их права доступа к разным частям web-приложения. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. При разработке дипломного проекта для этих целей использовалось средство ASP.NET, которое называется профили.

Информация о профилях пользователей содержится в специальной таблице базы данных aspnet_Profile, созданной с помощью программы aspnet_regsql.exe. Средство профилей интегрировано с моделью аутентификации ASP.NET так, что информация из профиля автоматически извлекается для текущего пользователя, когда это необходимо и записывается в базу данных в конце текущего запроса, если эта информация изменялась. Таким образом, профили сохраняются в индивидуальных записях, каждая из которых уникально идентифицирована именем пользователя.

Для того чтобы использовать профили в web-приложении необходимо сконфигурировать поставщик и свойства профилей в файле web.config. Ниже приведён код настройки свойства профилей для разработанного web-приложения:

<add name= "MySqlProvider"

type= "System. Web. Profile. SqlProfileProvider"

……………………………………………

applicationName="/MusicInternetShop"/>

</providers>

<……………………………………………………………………

</properties>

</profile>

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

Элемент <properties> специфицирует информацию, которая будет храниться в профиле. Помимо переменных стандартных типов C# в профиле можно сохранять также объекту пользовательских классов. Для хранения информации пользователя были разработаны три пользовательских класса. На рисунке 12 представлена диаграмма этих классов.

Рис. 12 "Диаграмм классов, используемых в профилях"

Объект класс UserInfo содержит информацию о фамилии, имени, отчестве покупателя, адресе и почтовом индексе, а также контактном телефоне.

Переменные классов объявлены как приватные, доступ к ним осуществляется через общедоступные свойства. Это позволяет использовать механизм привязки данных, который описан в пункте 3.3. Исходный код классов приведён в приложении №3.

Также в профиле сохраняется отдельная переменная SumPurchase типа decimal, она хранит общую сумму покупок пользователя в Интернет-магазине и используется для определения скидки.

В элементе <properties> файла web.config приведены следующие настройки свойств профиля:

· name - имя свойства;

· type - тип свойства;

· serializeAs - формат, используемый при сериализации. Возможные значения String, Binary, Xml. В данном случае используется двоичный формат Binary;

· allowAnonymous - если установлено в true, то это свойство применяется также и в анонимных профилях. Об анонимных профилях будет описано ниже.

Среда ASP.NET предоставляет программный интерфейс Profiles API для управления профилями пользователей. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении.

Ниже приведён код добавления товара в корзину покупателя:

protected void ImageButtonAddToCart_Click (object sender, ImageClickEventArgs e)

{

if (! IsPageRefresh && (Roles. IsUserInRole ("User") ||! User. Identity. IsAuthenticated))

{

……………………………………………….

{

if (_item. ProductID == productID)

{

// Если такой товар уже присутствует в корзине, то его кол-во увеличивается на единицу

_item. Quantity++;

Profile. Save();

………………………….

Session ["IsUpdateCart"] = true;

return;

}

// Если такой товар отсутствует в корзине, то он добавляется

ShoppingCartItem item = new ShoppingCartItem (productID, productName, unitCost, 1);

Profile. Cart. Add(item);

Profile. Save();

Session ["IsUpdateCart"] = true;

}

TrackRefreshState();

}

Как уже было сказано, выше свойство Cart может использоваться с анонимными профилями. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. Также необходимо разрешить анонимную идентификацию с помощью элемента <anonymousIdentification enabled= "true"/>. При этом сохраняется временный идентификатор пользователя, с помощью которого можно получить доступ к анонимному профилю. Механизм миграции анонимных профилей реализован через событие Profile_MigrateAnonymous, которое обработано в файле Global.asax, описанном в пункте 4.1.2. Это событие инициируется всякий раз, когда становится доступным анонимный идентификатор и текущий пользователь аутентифицируется. Анонимный профиль извлекается с помощью вызова Profile. GetProfile() с передачей анонимного идентификатора, данные из него переносятся в постоянный профиль, а затем анонимный идентификатор и профиль удаляются. Соответствующий код приведён ниже:

void Profile_MigrateAnonymous (Object sender, ProfileMigrateEventArgs pe)

{

ProfileCommon anonProfile = Profile. GetProfile (pe. AnonymousID);

if ((anonProfile. Cart. Count!= 0) && (Roles. IsUserInRole ("User")))

{

foreach (ComponentsShoppingCart. ShoppingCartItem _item in anonProfile. Cart)

{

……………………………………………………………

{

Profile. Cart [Profile. Cart. IndexOfByProductID (_item. ProductID)].Quantity += _item. Quantity;

}

else

{

…………………………….

}

Profile. Save();

}

try

{

Session ["IsUpdateCart"] = true;

}

catch (HttpException)

{}

System. Web. Profile. ProfileManager. DeleteProfile (pe. AnonymousID);

AnonymousIdentificationModule. ClearAnonymousIdentifier();

}

4.7 Основные элементы интерфейса музыкального Интернет-магазина

4.7.1 Регистрация нового покупателя

Регистрация нового покупателя происходит на странице Registration.aspx, изображение которой представлено на рисунке 13. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. Для сохранения дополнительная информация о пользователе было переопределено событие OnCreatedUser, которое инициируется после того, как мастер создал нового пользователя. Вся дополнительная информация сохраняется в профиле пользователя.

Также введена защита от автоматической регистрации. В данной дипломной работе некоторые фрагменты текста отсутствуют или замещены на текст не соответствующий теме этого диплома. Отсутствуют или не соответствуют некоторые необходимые формулы, расчеты, диаграммы и таблицы. Для получения оригинальной версии работы пишите на электронный адрес, указанный в конце дипломной работы, в заключении. Для реализации защиты было переопределено событие OnCreatingUser, которое инициируется перед тем как мастер создаёт нового пользователя. Если код с картинки не соответствует коду, указанному пользователю, то регистрация отменяется и выдаётся соответствующее сообщение.

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

4.7.2 Личные данные покупателя

Покупатель может изменять информацию о себе, сменить пароль и контрольный вопрос и ответ для восстановления пароля на странице UserPersonalData.aspx. При изменении личных данных информация, содержащаяся в профиле обновляется. Для смены пароля и контрольного вопроса и ответа, использовались методы предоставляемые интерфейсом MembershipAPI - ChangePassword() и ChangePasswordQuestionAndAnswer() соответственно. Изображения страницы UserPersonalData.aspx представлено на рисунке 14.

Рис. 13 "Страница регистрации нового покупателя"

4.7.3 Каталог продукции

Покупатель может просматривать каталог продукции на странице CatalogList.aspx. Переход на страницу осуществляется автоматически, когда покупатель выбирает один из критериев поиска товара, например, нажимает на ссылку в меню жанров. При этом на странице отображаются все товары, которые удовлетворяют этому критерию. Вывод осуществляется постранично по 15 записей. Для выборки данных используются методы, представленные в компоненте доступа к данным CatalogDB. На рисунке 15 представлено изображение страницы CatalogList.aspx, на которой выведены все альбомы, относящиеся к жанру Heavy Metal.

Рис. 15 "Страница каталога продукции"

На рисунке 16 представлено изображение страницы CatalogList.aspx с использованием расширенного поиска продукции.

4.7.4 Страница подробностей о продукции

Выбирая конкретный альбом на странице каталога, покупатель переходит на страницу ProductDetails.aspx, отображающую подробную информацию о выбранном альбоме, а также позволяющей добавить альбом в корзину товаров, просмотреть отзывы об альбоме или оставить свой. Изображение страницы ProductDetails.aspx представлено на рисунке 16. Ознакомившись с альбомом, покупатель может добавить альбом вы корзину товаров, нажав на иконку с изображением корзины.

Рис. 15 "Страница каталога продукции с использованием расширенного поиска"

4.7.5 Отзывы о продукции

Нажав на ссылку "Просмотреть отзывы" покупателель перейдёт на страницу Responses.aspx, где на которой будут отображены все отзывы покупателей о данном альбоме. На рисунке 17 представлено изображение страницы Responses.aspx. Покупатель может также сам оставить отзыв об альбоме, для этого необходимо нажать на ссылку "Написать отзыв" и заполнить появившуюся форму. Оставлять отзывы об альбомах могут только аутентифицированные пользователи. Пример представлен на рисунке 18.

Рис. 17 "Отзывы об альбоме"

Рис. 18 "Добавление отзыва об альбоме"

4.7.6 Корзина покупателя

Страницы: 1, 2, 3, 4