Электронная комерция

 
 
 
 
 
 
 
 
 
 
 
 

3. Программная часть интернет магазина 

3.1. Среда разработки 

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

• Развитые средства авторизации и аутентификации
• Защищённые каналы передачи информации
• Надёжное хранилище персональных данных пользователей
• Средства сохранения состояния при навигации по сайту
• Удобный и красивый пользовательский интерфейс

    По  совокупности перечисленных требований следует, что наиболее подходящей для поставленной задачи является платформа ASP.NET. 

3.2. Безопасность 

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

В основном для большей части Web-приложений основные задачи для реализации защиты всегда одни и те же: 

• Аутентификация - процесс определения идентичности пользователя и обеспечения гарантий этой идентичности. Прежде всего, вы должны аутентифицировать пользователей. Аутентификация задает вопрос: кто идет? В конечном итоге она определяет, кто работает с вашим приложением на другой стороне.
• Авторизация - процесс определения прав и ограничений, назначенных аутентифицированному пользователю. В зависимости от идентифицирующей вас информации, вам либо открывается, либо закрывается доступ к запрошенным ресурсам. Т.е. как только вы узнали, кто работает с вашим приложением, ваше приложение должно решить, какие операции данный пользователь может выполнять и к каким ресурсам обращаться. Другими словами, авторизация отвечает на вопрос: каков ваш уровень допуска?
• Конфиденциальность. Когда пользователь работает с приложением, вы 
  должны гарантировать, что никто другой не сможет видеть важные данные, 
  которые он обрабатывает. Таким образом, вы должны шифровать канал между браузером клиента и Web-сервером. Более того, возможно, вам придется 
  шифровать данные, сохраняемые в базе данных, чтобы даже администратор базы данных или другой персонал вашей компании не мог видеть эти данные. Конфиденциальность означает обеспечение невидимости данных для неавторизованных пользователей во время передачи их по сети или сохранении в хранилищах, таких как базы данных.
• Целостность. И, наконец, вы должны гарантировать, что данные, передаваемые между клиентом и сервером, не изменяются в результате неавторизованного вмешательства. Цифровые подписи позволяют снизить уровень этой 
  угрозы. Целостность это обеспечение невозможности изменения данных никем во время передачи по сети или сохранения в хранилище.

 

Итак, как же всё вместе работает?

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

Аутентификация 

В приложениях  ASP.NET аутентификация реализуется одной из четырех возможных аутентифицирующих систем:

• Аутентификация Windows.
• Аутентификация с помощью форм.
• Аутентификация с помощью паспортов.
• Специализированный процесс аутентификации.

В каждом случае пользователь предъявляем некоторое удостоверение при регистрации в системе. Идентичность пользователя отслеживается разными способами, в зависимости от типа аутентификации. Например, операционная система Windows использует 96-битное число, называемое SID (Security Identifier - идентификатор безопасности) для идентификаций каждого входящего пользователя. В аутентификации форм ASP.NET пользователю выдается аутентифицирующий мандат формы, представляющий собой комбинацию значений, которые шифруются и помещаются в cookie-набор.

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

Аутентификация  с помощью форм 

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

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

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

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

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

Почему стоит использовать аутентификацию форм? 

Аутентификация cookie-набором — привлекательный  выбор для разработчиков по нескольким причинам: 

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

 

Рассмотрим  каждый из этих аргументов по очереди. 

Контроль  над кодом аутентификации

Поскольку аутентификация форм реализована полностью  внутри ASF.NET, вы получаете полный контроль над выполнением аутентификации. Вам не нужно полагаться ни на какую внешнюю систему, как это имеет место при аутентификации Windows иди Passport. Вы можете настроить поведение аутентификации формы под свои нужды. 

Контроль  над внешним видом формы регистрации

Вы имеете ту же степень контроля над внешним  видом аутентификации форм, что и  над ее функциональностью. Другими словами, вы можете оформлять входную страницу регистрации как вам угодно. Гибкость внешнего вида недоступна при других методах аутентификаций. Аутентификация Windows требует, чтобы браузер запрашивал пользовательское удостоверение, а Passport аутентификация требует, чтобы вы оставили свой Web-сайт и посетили сайт Passport для ввода своей регистрационной информации (удостоверения). 
 

Работа  с любым браузером

Аутентификация  форм использует в качестве пользовательского интерфейса стандартный HTML, так что все браузеры могут его обработать. Поскольку вы можете оформлять регистрационную страницу так, как вам нравится, вы можете даже использовать аутентификацию форм с браузерами, которые не используют HTML, — например, с мобильными устройствами. Чтобы сделать это, вы должны определить применяемый браузер и представить форму в корректном формате для данного устройства (таком как WML для мобильных телефонов).

Хранение  информации о пользователях

Аутентификация  форм по умолчанию хранит пользователей в файле web.config, но эту информацию можно хранить где угодно. Для этого нужно только создать код, который обращается к хранилищу данных и извлекает информацию о пользователях. (А если вы применяете интерфейс Membership API, представленный в главе 21, то вам и этого делать не придется). Общим примером может служить хранение информации о пользователях в базе данных.

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

По сравнению  с этим Windows-аутентификация намного менее гибка. Она требует установки учетной записи пользователя Windows для каждого пользователя, которого вы хотите аутентифицировать. Это представляет очевидную проблему, если вы хотите обслуживать огромное число пользователей или хотите регистрировать пользователей программно» Это также не позволяет вам сохранять дополнительную информацию о пользователях. (В случае применения службы Active Directory у вас есть возможность расширить схему, но это нечто такое, что требует тщательного планирования). Ее приходится сохранять отдельно. Passport-аутентификация имеет аналогичные ограничения. Хотя Passport сохраняет больше пользовательской информации, он не позволяет вам добавлять свою, как и не дает возможность принять участие в регистрации пользователей и администрировании учетных записей.  
 

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

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

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

Первые  два недостатка можно устранить, применяя интерфейс 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. Любая функциональность, перечисленная выше, работает совершенно независимо от конкретного используемого хранилища данных, и одни хранилища данных можно заменять на другие - совершенно без необходимости какой-либо модификации приложений.