CommuniGate Pro: Модуль Веб Інтерфейсу Користувача
версія 6.2
Коли користувач вказує своєму браузеру з'єднатися з сервером CommuniGate Pro через порт для Веб Інтерфейсу Користувача, відображається сторінка Входу на сервер. Порт для Веб Інтерфейсу Користувача задається в настройках HTTP модуля Користувача ; за замовчуванням використовується незахищений порт номер 8100 і безпечний (на деяких платформах не встановлює за замовчуванням) порт номер 9100.
WebUser модуль здійснює перевірку імені домена з URL і показує сторінку Входу для цього домену. Якщо сервер CommuniGate Pro provider.com має додатковий домен client.com, то при використанні URL <http://provider.com: port> буде показана сторінка Входу для домену provider.com, а при використанні URL <http: // client. com: port> буде показана сторінка входу для домену client.com, навіть якщо домен client.com не має призначеного IP адреси .
Коли WebUser модуль отримує ім'я домену з URL, він проганяє його через записи маршрутизатора Рівня Домену. Так, якщо в таблиці маршрутизатора є запис:www.client.com = client.com
то URL <http://www.client.com:port> буде оброблятися як URL <http://client.com:port> і також призведе до висновку сторінки Входу для домену client.com.Якщо в URL міститься ім'я домену, яке обслуговується сервером CommuniGate Pro, то показується сторінка з повідомленням про помилку. Зазвичай це свідчить про помилку в налаштуванні Сервера: вказаний домен має A-запис в DNS, яка вказує на ваш сервер (так як в іншому випадку сервер не отримав би цей запит), але його ім'я не направляється ні на який з доменів, що обслуговуються вашим північчю . Ви повинні або створити домен з таким ім'ям у CommuniGate Pro, або перенаправити цей домен на один з вже існуючих доменів CommuniGate Pro.
Якщо в URL міститься не ім'я домену, а IP адреса, то модуль WebUser намагається знайти домен CommuniGate Pro, якому призначений таку адресу. Якщо такий домен не знайдено, то відкриється сторінка Входу для головного домену.
Користувач може зайти на сервер як користувач з будь-якого домену, якщо він вкаже своє повне ім'я: якщо, наприклад, відкрита сторінка Входу головного домену Сервера (<http://provider.com: port>), а Ім'я Користувача у відповідному полі введено як [email protected], то на сервер увійде користувач username з домену client.com (якщо був також вказана правильна пароль).
Якщо в домені існують Списки розсилки, то його сторінка Входу містить посилання на сторінки з архівами списків Розсилання .
Якщо в домені включена Вільна Реєстрація користувачів, то на сторінці Входу домену також показується посилання на сторінку реєстрації .
Якщо Домен має користувальницький Сертифікат Безпеки, то показується посилання на Сертифікат. Якщо користувач клацне по цьому посиланню, то він зможе встановити в своєму браузері Сертифікат Домену як довірений сертифікат.
Деякі протоколи (такі як IMAP і POP) є сесійно-орієнтованими протоколами: клієнтську програму встановлює з'єднання з сервером, надає дані, необхідні для аутентифікації користувача, обробляє дані користувача (папки, настройки і т.п.) і потім закриває з'єднання. HTTP протокол не є сесійно-орієнтованим: Веб-браузер встановлює з'єднання, відправляє один або кілька запитів, отримує дані і закриває з'єднання.
Щоб забезпечити таку ж функціональність, як і при проведенні повноцінної сесії, в модулі WebUser реалізований так званий сервер додатків: коли користувач аутентифікований через сторінку Входу, створюється віртуальна сесія. Віртуальна сесія фактично є деякою внутрішньою структурою даних на сервері, що зберігає інформацію про користувача, його відкритих папках і інших сесійно-орієнтованих даних, але така структура не прив'язана до якогось певного мережевого з'єднання. Коли користувач працює з сервером через браузер, модуль WebUser направляє запити браузера в одну з уже відкритих віртуальних сесій.
Для того, щоб направляти запити правильним чином, модуль WebUser створює ідентифікатор сесії (ID сесії) для кожної створюваної віртуальної сесії і змушує браузер користувача включати ідентифікатор сесії в кожен відправляється їм запит.
Для того, щоб уникнути "захоплення" WebUser сесій, модуль WebUser запам'ятовує мережевий (IP) адреса, з якого був отриманий запит на вхід і направляє в сесію дані тільки якщо подальші запити отримані з цього ж адреси.
Зверніть увагу: Іноді, якщо користувач з'єднується через проксі сервер, запити користувача приходять на сервер з різних IP адрес (якщо проксі сервер використовує кілька мережевих адрес). У цьому випадку користувач повинен вимкнути опцію контролю адреси на сторінці налаштувань Веб інтерфейс користувача. Зазвичай користувачі великих провайдерів (таких, як AOL, WebTV) виходять в Інтернет через проксі сервера провайдера, так що вони повинні вимикати опцію контролю адреси.
Або ж додайте діапазон IP Адрес проксі в список Адреси NAT серверів .
Всі адреси IP, що належать діапазонами з цього списку, вважаються однаковими.
Для того, щоб уникнути "захоплення" сесій WebUser, модуль WebUser може використовувати HTTP "cookies". Коли опція Захист за допомогою Cookies включена, Сервер створює якусь випадкову "cookie" рядок і відправляє її браузеру користувача при встановленні сесії. Потім, коли браузер отримати доступ до будь-яких сторінок з даними протягом цієї сесії, він завжди відсилає цей рядок назад на Сервер. Сервер дозволяє доступ тільки якщо їм отримана правильна рядок "cookie".
Зверніть увагу: Деякі браузери не підтримують "cookies" взагалі або підтримка "cookies" в них може бути виключена. Перед тим, як включати опцію Захист за допомогою Cookies, Користувач повинен перевірити настройки браузера.
Зазвичай, користувач починає свою WebUser сесію ввівши Ім'я Користувача і пароль на сторінка Входу через Веб інтерфейс користувача. Це "незахищений" метод входу, і він є безпечним тільки якщо доступ до сторінки Входу здійснюється через захищене (SSL / TLS) з'єднання (через URL виду https: //).
В якості альтернативи може використовуватися URL / login / на вашому Сервері. Сервер зажадає проведення Аутентифікації на рівні HTTP, і браузер або відкриє діалогове вікно Аутентифікації, або, якщо встановлено безпечне SSL / TLS з'єднання, відправить Сертифікат Користувача.
При створенні складного сайту, що пропонує цілий набір Веб Послуг ( "Порталу"), може знадобитися створення сесії WebUser без перенаправлення користувача на сторінку Входу. Для цієї мети може бути використаний наступних механізм.
Автоматизація Входу направте браузер за посиланнямhttp: // your.server.domain [: port] /? username = імяАккаунта & password = пароль
HTTP Аутентификация направте браузер за посиланнямhttp: // your.server.domain [: port] / login /
Якщо браузер автоматично входить на сервер через цей розділ, то діалог Входу стане нормальним користувачеві. Аутентифікація За Сертифікату направте браузер за посиланнямhttp: // your.server.domain [: port] / login /
Якщо Домен підтримує сертифікати Клієнтів і на комп'ютері користувача встановлено належний сертифікат, то браузер автоматично входить на сервер через цю область, і діалог Входу стане нормальним користувачеві. Створення Сесії через CLI для створення сесії WebUser використовуйте Мережевий Інтерфейс командного Рядки CLI / API , Потім направте браузер за посиланнямhttp: // your.server.domain [: port] / Session / sessionID /Hello.wssp
Автоматизація Входу з використанням ідентифікатора інший Сесії направте браузер за посиланнямhttp: // your.server.domain [: port] /? username = імяАккаунта & password = ідентіфікаторСессіі & SessionIDMethod = yes
Цей механізм нічим не відрізняється від описаного раніше механізму Автоматизації Входу, за винятком того, що замість незахищеного методу Аутентифікації буде використовуватися метод Аутентифікації через SessionID . Параметр sessionID є ідентифікатором будь-який інший існуючої WebUser або XIMSS сесії для того ж користувача імяАккаунта.Для того, щоб налаштувати модуль Веб Інтерфейсу Користувача, за допомогою будь-якого браузера з'єднаєтеся з Сервером CommuniGate Pro і відкрийте сторінку WebUser в розділі Установки.
Обмеження Використовуйте ці настройки для завдання максимального числа одночасно обслуговуваних сесій Веб Інтерфейсу Користувача.Зверніть увагу: пам'ятайте, що з'єднання, що встановлюються браузером (HTTP) це не те ж саме, що сесії WebUser. Зазвичай достатньо підтримувати 100 одночасних HTTP каналів для обслуговування 5000 Сесій. Рівень Журналу Використовуйте цей параметр, щоб вказати, яку інформацію модуль Веб Інтерфейсу Користувача повинен зберігати в Журналі роботи Сервера. Зазвичай використовується рівень Основні (звіти про доставку Ваших повідомлень).
Записи, поміщені модулем Веб Інтерфейсу Користувача в Журнал роботи Сервера, мають позначку WEB. Тайм-аут по неактивних Використовуйте це налаштування для завдання максимального інтервалу часу між зверненнями клієнта (браузера) до певної Сесії WebUser. За допомогою цієї настройки можна виробляти від'єднання тих користувачів, які не завершили свою сесію коректно або тих, хто просто закрив свій браузер або перейшов на інший Веб сайт. Не вказуйте тут занадто мале значення, так як в цьому випадку ваші користувачі можуть бути відключені від сервера під час написання листа. Обмеження часу Сесії Використовуйте це налаштування для завдання максимальної тривалості WebUser сесії. Це обмеження перевіряється, коли браузер встановлює з'єднання і отримує сторінки з даними протягом сесії, так що немає сенсу ставити тут значення менші, ніж в Тайм-аут по неактивних. Обмеження на Відправку: Одержувачі Використовуйте це налаштування для вказівки максимального числа адрес електронної пошти, яке може міститися в повідомленні, створеному через Веб інтерфейс користувача.
Відкрийте установки Модуля HTTPU і знайдіть розділ Доп. протоколів:
Установка Доступ визначає, клієнти з яких мереж можуть створювати сесії WebUser.
Адміністратор Сервера може вказати одну або кілька зовнішніх програм перевірки орфографії. Для настройки перевірки орфографії, натисніть на посилання Орфографія на сторінці Загальні.
З'явиться сторінка Орфографія:Для настройки перевірки орфографії, вкажіть мову, який програма повинна обробляти, шлях до програми і кодування, в якій програма обробляє дані. Для внутрішнього представлення даних в Сервері використовується кодування UTF-8, так що, якщо перекодування не потрібно, встановлюйте значення UTF-8.
Під час налаштування Рівень Журналу для вказівки, яку інформацію Модуль перевірки орфографії повинен зберігати в Журналі роботи Сервера.
Записи, поміщені модулем перевірки орфографії в Журнал роботи Сервера, мають позначку SPELLER.
Ви можете встановити (або скинути) прапорець для включення (виключення) використання певної програми перевірки орфографії, не видаляючи її зі списку програм.
Для того, щоб видалити програму перевірки орфографії, введіть порожній рядок в поле Мова натисніть кнопку Модифікувати.
Програми перевірки орфографії повинні підтримувати роботу через інтерфейс "pipe", який використовується в популярних програмах Ispell і aspell:На сторінці Входу в Домен, модуль WebUser показує посилання на Списки Розсилання.
Сторінка з Списками Розсилання містить всі списки розсилки цього домену, для яких Права Перегляду дані всім. Кожне ім'я є посиланням, пройшовши по якій можна відкрити сторінку зі списком повідомлень в цьому Списку Розсилання. Так як архіви Списків Розсилання зберігаються в папках, робота в Веб інтерфейс зі списками розсилки дуже схожа на роботу в Веб інтерфейс при перегляді Тек .
При роботі зі списками розсилки через Веб інтерфейс користувача не потрібно ніякої аутентифікації і не створюється віртуальна сесія; кожен запит браузера обробляється незалежно.
Якщо в домені опція вільної Реєстрації включена, то на сторінці Входу є посилання на сторінку Реєстрації. Це сторінка дозволяє новому користувачеві ввести ім'я, пароль, "реальне ім'я" і створити нового користувача на сервері.
Коли створюється новий користувач, його опції і установки беруться з Шаблона Домену.
Керівництво CommuniGate® Pro. Copyright © 1998-2019, Stalker Software, Inc.