2015-09-06
244
Раніше ми розгледіли|розглядали| ряд|лаву| допоміжних функцій і описів об'єктів, використовуваних в інтернет-магазині.
Тепер розгледимо|розглядатимемо| просту ASP-сторінку| (search|.asp), що забезпечує логіку роботи з|із| каталогом товарів.
Для роботи з|із| каталогом, буде потрібно мінімальний набір функцій:
· пошук і проглядання записів каталогу;
· редагування;
· додавання|добавляти| записів.
У реальному електронному магазині, набір функцій може бути значно ширше і включати:
· протоколювання операцій по зміні каталогу;
· обчислення|підрахунок| індивідуальних цін на підставі знижок, встановлених|установлених| для клієнта;
· публікація описів і зображень товарів.
При великій кількості товарів, не обійтися також і без функції синхронізації каталогу товарів магазина з|із| номенклатурним довідником в офф-лайновій| обліковій системі (1С|, Галактика і так далі). Синхронізація, може виконуватися шляхом експорту номенклатурного довідника, з|із| облікової системи і імпорту даних в каталог інтернет-магазину. У простому випадку можна обійтися і без автоматичної синхронізації.
|
|
|
Оскільки|тому що| ми вже визначили ряд|лаву| низько рівневих об'єктів і функцій, то початковий|вихідний| текст модуля для управління каталогом товарів буде досить простим.
7.7.3. Авторизація відвідувачів|візитерів| інтернет-магазину
Авторизація відвідувачів|візитерів| потрібна по двох основних причинах:
· надання відвідувачеві|візитерові| відповідних прав для зміни інформації на сайті;
· забезпечення можливості|спроможності| створення|створіння| корзини|кошика| замовлення для конкретного покупця.
При роботі інтернет-додатка для кожного відвідувача створюється спеціальний програмний об'єкт, який називається «сесією» (Session).
При першому зверненні до сайту для відвідувача створюється нова сесія. Все подальші звернення виконуються в рамках створеної сесії. Час життя сесії (session timeout) визначається налаштуваннями сервера і за умовчанням дорівнює 20 хвилинам. Протягом цього часу сервер зберігає всі дані сесійної змінної, після чого сесія знищується і виділена під сесію область пам'яті звільняється. Кожне звернення відвідувача до сервера, продовжує час на чергових 20 хвилин.
У кожен момент часу, число активних сесій відповідає числу активних відвідувачів|візитерів| за останніх 20 хвилин.
Ідентифікатор сесії це унікальний ключ|джерело|, він створюється при першому зверненні до сторінки сервера і передається назад браузеру|. При черговому запиті, браузер| передає цей ключ|джерело| серверу, а той у свою чергу|в свою чергу| перевіряє наявність сесії з|із| таким ключем|джерелом|. Якщо така сесія існує, то вона, і всі збережені в ній значення, стають доступними серверному застосуванню.
|
|
|
Об'єкт Session може зберігати не лише унікальний ключ сесії, але і різні змінні. Наприклад, ідентифікатор користувача і корзину товарів, що дозволяє виключити необхідність передачі ідентифікатора і пароля користувача при кожному зверненні до сайту, забезпечуючи при цьому необхідний рівень інформаційної безпеки.
Механізм сесій в MS Internet Information Server (MS IIS) працює тільки за умови підтримки браузером відвідувача так званих session cookies. У налаштуваннях браузера можна заборонити підтримку session cookies, і тоді при кожному зверненні до сервера створюватиметься нова порожня сесія.
У переважній більшості випадків підтримка, session| cookies| у відвідувачів|візитерів| включена. Але|та| інколи|іноді| користувачі Інтернету, що начулися про проломи в системі безпеки браузерів|, відключають цю підтримку. Такі проломи дозволяють недобросовісним|несумлінним| сайтам прочитувати cookies|, що залишилися в кеші браузера| після|потім| відвідин|відвідувань| інших сайтів (відмітимо|помітимо|, що не дуже технічно грамотних сайтів).
Передбачати чи ні|або ні| можливість|спроможність| роботи відвідувача|візитера| Вашого сайту без cookies| – вирішувати|рішати| Вам.
Для нашого інтернет-застосування безпека cookies| неістотна|несуттєва|, оскільки|тому що| ми не збираємося зберігати в cookies| ні номера кредитних карт, ні ідентифікаторів, ні паролів. І вам не радимо.
Для критичніших до інформаційної безпеки застосувань можемо порекомендувати використовувати механізми «емуляції сесій». Наприклад, шляхом додавання|добавляти| до URL-адресу| власного сесійного ключа|джерела|. Ще безпечніше використовувати систему аутентифікації на базі цифрових сертифікатів. Проте|однак|, ці питання виходять за межі нашої статті.
Щоб|аби| зробити|вчинити| покупку|купівлю| в магазині, покупець може бути не реєстрованим користувачем (має на це право). І в цьому випадку описаний вище механізм чудово виконує свої завдання|задачі|. Він дозволяє анонімному покупцеві проглядати каталог, формувати корзину|кошик| замовлення, відправляти|відряджати| сформоване замовлення на обробку. При цьому всі необхідні для процесу параметри зберігаються в об'єкті Session|.
Якщо покупець є|з'являється| зареєстрованим користувачем, то після|потім| авторизації система може автоматично заповнювати адресні поля замовлення і зберігати реєстр замовлень по кожному покупцеві. Погодитеся – це зручно.
У нашому застосуванні для зберігання даних про зареєстрованих користувачів використовується таблиця Users|. В процесі авторизації користувач повинен вказати свій ідентифікатор і пароль. Якщо в таблиці є|наявний| запис з|із| таким ідентифікатором і паролем, то система ідентифікує відвідувача|візитера| і наділяє його необхідним рівнем прав на роботу з|із| інформацією.
