Разработка алгоритма работы электронного магазина

Когда не следует применять аутентификацию форм?

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

· Вы должны самостоятельно создавать пользовательский интерфейс для регистрации пользователей.

· Вы должны поддерживать каталог удостоверений пользователей.

· Вы должны предпринимать дополнительные предосторожности против вмешательства в сетевой трафик.

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

Membership API (интерфейс «членства»).

C одной стороны, аутентификация с помощью форм закладывает важный фундамент реализации безопасных пользовательских форм регистрации для ваших приложений ASP.TSET. С другой стороны, задачи, которые вам приходится решать в процессе создании форм регистрации и взаимодействия с лежащим в основе хранилищем удостоверений, почти всегда одни и те же дли каждого Web-приложения. и они достаточно утомительны. Следует иметь в виду и еще один момент: аутентификация с помощью форм предоставляет инфраструктуру только для аутентификации пользователей, и если вы используете собственное хранилище удостоверений, то вам придется писать административные приложения для управления пользователями.

Вот почему команда ASP.NET получала так много откликов от сообщества разработчиков. В результате в ASP-NET 2.0 был добавлен новый программный интерфейс Membership API (интерфейс «членства»). Интерфейс Membership API -- эта каркас, построенный на базе существующей инфраструктуры аутентификации форм. При использовании Membership API вам даже не нужно реализовывать страницы регистрации или хранилища удостоверений.

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

· Возможность создавать и удалять пользователей -- как программно, так и с помощью Web-утилиты конфигурирования ASR.NET

· Возможность переустановки паролей с автоматической отправкой пользователям новых паролей по электронной почте, если известен адрес электронной почты данного пользователя.

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

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

· Набор предварительно разработанных элементов управления для создания страниц регистрации и отображения состояния регистрации в различных видах для аутентифицированных и неаутентифицированных пользователей.

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

3.4 API-интерфейс Membership

API-интерфейс Membership -- это завершенная система управления пользователями. Она помогает вам создавать, редактировать и удалять пользователей, а также включает функциональность восстановления паролей. Этот АРI-интерфейс можно применять для программной реализации этих управленческих задач, или же, использовать Web-ориентированный инструмент конфигурирования ASP.NET для графического администрирования ваших пользователей. Благодаря данной инфраструктуре, вы можете сэкономить много времени, поскольку более нет необходимости создавать свой собственные приложения администрирования пользователей, потому что они уже существуют в каркасе ASP.NET 2.0, Более того, он включает также функциональность проверки комбинаций имен и паролей, вводимых пользователями.

3.5 API-интерфейс Roles

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

3.6 API-интерфейс Profiles

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

3.7 Управление состоянием

Ни одна среда для разработки Web-приложений, какой бы совершенной она не была, не может изменить тот факт, что HTTP является протоколом, который не сохраняет никакой информации о состоянии. После первого Web-запроса клиент отключается от сервера, и механизм ASP.NET очищает объекты страницы. Такая архитектура позволяет Web-приложениям обслуживать одновременно тысячи запросов, не истощая полностью ресурсы памяти сервера. Недостатком является то, что код должен использовать другие технологии для хранения информации между Web-запросами и ее извлечения в случае необходимости.

ASP.NET включает целый ряд опций для управления состоянием, прежде всего это состояние сеанса Session и состояние приложения Application.

Состояние сеанса (Session). Состояние сеанса -- это самая сложная технология для управления состояниями. Она позволяет сохранять информацию на одной странице и затем получать к ней доступ с другой страницы, а также поддерживает объекты любого типа, включая специальные, создаваемые самим разработчиком, типы данных. Лучше всего то, что состояние сеанса использует тот же основанный на коллекциях синтаксис, что и состояние вида. Единственное отличие -- имя встроенного свойства страницы, которое в данном случае выглядит как Session.

Каждый клиент, который получает доступ к приложению, имеет свой сеанс и свою отдельную коллекцию данных. Состояние сеанса идеально подходит для сохранения таких данных, как элементы, которые находятся в корзине для покупок пользователя, когда он переходит с одной страницы на другую. Но использование состояния сеанса имеет свою цену. Хотя оно решает многие из проблем, которые возникают в случае применения других технологий управления состояниями, его использование вынуждает Web-сервер сохранять дополнительную информацию в памяти. Эта необходимость в использовании дополнительных ресурсов памяти сервера, пусть даже в маленьком объеме, очень быстро может достичь угрожающего производительности уровня, когда к сайту начнут получать доступ сотни или тысячи клиентов.

Состояние приложения (Application). Состояние приложения позволяет сохранять глобальные объекты, доступ к которым может получать любой клиент. В основе состояния приложения лежит класс System.Web.HttpApplicationState, который доступен на всех Web-страницах через встроенный объект Application. Состояние приложения похоже на состояние сеанса. Оно поддерживает объекты такого же типа, хранит информацию на сервере и использует синтаксис такого же словарного стиля. Элементы состояния приложения хранятся в виде объектов, поэтому при извлечении из коллекции они должны приводиться к соответствующему типу. Время жизни элементов состояния приложения никогда не истекает. Они существуют до тех пор, пока приложение или сервер не будет перезапущен.

Состояние приложения также может применяться для хранения часто используемой информации, создание которой отнимает много времени (такой как полный каталог товаров, который требует выполнения поиска в базе данных). Однако использование для хранения такой информации коллекции Application приводит к появлению различных проблем вроде того, как проверить, являются ли данные действительными, и как заменить их в случае необходимости. Это также может негативно сказаться на производительности, если каталог продуктов является слишком большим.

Кроме этого, существуют и другие опции для управления состоянием - это состояние вида, строка запроса, cookie-наборы.

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

Наиболее распространенный подход передавать информацию с помощью строки запроса в URL-адресе. Именно этот подход часто применяется в поисковых службах. Например, при выполнении поиска на Web-сайте Google пользователь перенаправляется на новый URL-адрес, который включает заданные условия поиска: http://www.google.ru/search?hl=ru&q=internet+shop

Строка запроса - это та часть URL-адреса, которая находится после вопросительного знака. В данном случае она определяет одну единственную переменную с именем q, которая содержит строку internet+shop.

Специальные cookie-наборы - это еще один способ сохранения информации для последующего использования. Cookie-наборы представляют собой небольшие файлы, которые создаются на жестком диске клиента (или, если они являются временными, в памяти Web-браузера). Одним из преимуществ cookie-наборов является то, что они работают "автоматически", и пользователь даже не знает о том, что должна быть сохранена какая-то информация. Они также могут запросто использоваться любой страницей в приложении и даже сохраняться между посещениями, что подразумевает действительно долгосрочное хранение. Они обладают рядом таких же недостатков, что и строки запросов. А именно -- они могут хранить только простую строковую информацию, и пользователь очень легко может получить к ним доступ и просмотреть их, отыскав и открыв соответствующий файл. Эти факторы делают их неподходящим вариантом, когда требуется сохранить сложную или секретную информацию или просто большой объем данных.

Заключение

Глобальная сеть Internet сделала электронную коммерцию доступной для фирм любого масштаба. Если раньше организация электронного обмена данными требовала заметных вложений в коммуникационную инфраструктуру и была по плечу лишь крупным компаниям, то использование Internet позволяет сегодня вступить в ряды «электронных торговцев» и небольшим фирмам.

Одно из главных достоинств электронной коммерции -- возможность купить какой-либо товар не выходя из дома.

Под определение электронной коммерции подпадают системы, ориентированные на Internet - «электронные магазины».

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

Таким образом, для качественно разработанного Интернет - магазина с полной функциональностью и защищённостью требуется следующее:

· Развитые средства авторизации и аутентификации

· Защищённые каналы передачи информации

· Надёжное хранилище персональных данных пользователей

· Средства сохранения состояния при навигации по сайту

· Удобный и красивый пользовательский интерфейс

Список литературы

1. Дэниел Эймор «Internet-магазины и закупочная деятельность» - «Электронный бизнес. Эволюция и революция» изд. «Вильямс» 2001, с.291-302

2. Балабанов И.Т. «Торговля через виртуальный магазин» - «Электронная коммерция» 2004, с.195-197

3. «Создание интернет-магазинов» - www.astastred.com.ru

4. Ляхов А.Е. «Краткий курс электронной торговли» - www.lyahov.kz

5. М. Мак-Дональд, М. Шпушта «Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов» изд. «Вильямс» 2006, 1407с

6. Информация с Веб-сайта «Электронные платежные системы», http://www.emoney.ru

7. Информация с Веб-сайта «Reksoft. Электронная коммерция», http://www.reksoft.ru

Размещено на Allbest.ru