CommuniGate Pro
Версия 6.2
Доступ
 
 
Обзор

Доступ к данным Пользователей

Можно использовать различные клиентские приложения для доступа к данным пользователей на сервере CommuniGate Pro: Папкам, Календарям, Контактам, Файлам и так далее.

  • Модуль POP - это POP3 сервер; этот модуль позволяет пользователям забирать сообщения из своей папки INBOX (и, при необходимости, из других папок), используя почтовые программы, работающие по протоколу POP3.
  • Модуль IMAP - это сервер по протоколу IMAP4rev1; этот модуль позволяет пользователям обрабатывать сообщения в любых папках аккаунта, используя почтовые программы, работающие по протоколу IMAP.
  • Модуль Веб Интерфейса - это HTTP (Веб) сервер приложений; этот модуль позволяет пользователям работать с сообщениями, находящимися в любых папках и использовать другие возможности, предоставляемые сервером CommuniGate Pro через любой веб браузер.
  • Модуль XIMSS - это сервер XML Сообщений, Расписаний и Сигналов; этот модуль позволяет пользователям совершать телефонные вызовы и управлять ими, работать с сообщениями, находящимися в любых папках, работать с расписаниями и заданиями как индивидуально, так и в режиме группового взаимодействия, а также использовать другие возможности, предоставляемые сервером CommuniGate Pro совместно с насыщенными функциональными возможностями Веб клиентами (в частности, с клиентами, использующими Flash® технологию).
  • Модуль MAPI является расширением модуля IMAP; с его помощью пользователи получают доступ к информации на сервере через Microsoft® Windows MAPI (Mail API) и используют Microsoft Outlook в полнофункциональном режиме группового взаимодействия с аккаунтами на сервере CommuniGate Pro.
  • Модуль AirSync является расширением модуля HTTP; с его помощью пользователи могут получать доступ к папкам и аккаунтам на сервере через протокол Microsoft® ActiveSync и использовать клиентское ПО на мобильных платформах для отправки и получения почтовых сообщений, синхронизации Контактов, Календарей и Заданий между мобильным приложением и аккаукнтом на сервере CommuniGate Pro.
  • Модуль CalDAV является расширением модуля HTTP; он позволяет пользователям получать доступ к папкам с Календарями и Заданиями по протоколу CalDAV.
  • Модуль CardDAV является расширением модуля HTTP; он позволяет пользователям получать доступ к папкам с Контактами по протоколу CardDAV.
  • Модуль HTTP реализует сервер по протоколу HTTP, который используется в качестве транспортного уровня другими модулями (такими, как AirSync и WebDAV, Модулем XIMSS в режиме HTTP Binding, и т.д.), а также обеспечивает доступ к Хранилищу Файлов пользователя, к его Папкам и информации, необходимой для работы в группах.
  • Модуль FTP - сервер по протоколу FTP; этот модуль обеспечивает доступ к Хранилищу Файлов пользователя.
  • Модуль TFTP - сервер по протоколу TFTP; этот модуль обеспечивает доступ к Хранилищу Файлов пользователя.
  • Модуль ACAP - ACAP сервер; этот модуль позволяет управлять настройками приложений пользователя, хранимыми в произвольных наборах данных пользователя.

Доступ к данным Пользователей

Каждый пользователь может получать доступ к CommuniGate Pro через различные модули доступа - POP, IMAP, XIMSS, Веб Интерфейс Пользователя, FTP, XMPP и т.д. Несколько приложений могут работать с информацией пользователя в одно и то же время, используя как один и тот же, так и разные модули доступа или услуг.

Доступ к любой Папке любого Пользователя в CommuniGate Pro может быть совместным: то есть, доступ к папке может быть предоставлен не только пользователю-владельцу этой папки, но так же и другому пользователю, при условии что сам пользователь или Администратор предоставили другим пользователям соответствующие права.


Обслуживание нескольких доменов

Основной проблемой при обслуживании нескольких доменов на одном сервере является предоставление доступа пользователям в различных доменах. Чтобы найти пользователя с указанным именем, сервер должен получить имя домена, в котором его следует искать.
Доступ производится аналогично доставке сообщений или обработке Сигналов: сервер должен знать "полное имя пользователя" - адрес в форме accountname@domainname.

Существует несколько способов передачи имени домена серверу:

Эти методы могут использоваться в комбинации: некоторое число доменов может иметь выделенные для них IP адреса, в то время как для других будет требоваться явное указание доменного имени.


Системы с несколькими IP адресами

Каждая сессия доступа к Серверу начинается с процедуры аутентификации: клиентское приложение посылает на Сервер имя пользователя и пароль.

Сервер CommuniGate Pro пытается определить какой домен он должен использовать для поиска указанного имени.

Пример:
Сервер имеет 2 IP адреса: 192.0.0.1 и 192.0.0.2.
Главный домен сервера company.com, а добавочные домены client1.com и client2.com.
A-запись в DNS для домена company.com указывает на IP адрес 192.0.0.1,
A-запись для домена client1.com указывает на IP адрес 192.0.0.2, а A-запись для домена client2.com указывает на тот же самый "главный" IP address 192.0.0.1.
В каждом домене есть пользователь с именем info.

Три пользователя настроили свои клиентские программы для доступа к аккаунту info, но они указали разное значение настройки "сервер": первый ввёл company.com, второй - client1.com, а третий пользователь - client2.com.

Когда первый пользователь запускает свою почтовую программу:
  • Клиентское приложение берет указанный в настройке "сервер" company.com, и использует A-запись в DNS для преобразования этого имени в IP-адрес 192.0.0.1.
  • Клиентское приложение устанавливает связь по этому адресу (который является одним из двух адресов Сервера) и передаёт Серверу имя аккаунта info.
  • Сервер определяет, что указано простое имя аккаунта info и соединение установлено через адрес 192.0.0.1.
  • Сервер определяет, что этот IP адрес соответствует Главному Домену и добавляет имя Главного Домена company.com к указанному простому имени.
  • Сервер формирует корректное полное имя пользователя info@company.com.

Когда второй пользователь запускает своё клиентское приложение:

  • Клиентское приложение берет указанный в настройке "сервер" client1.com, и использует A-запись в DNS для преобразования этого имени в IP-адрес 192.0.0.2.
  • Клиентское приложение устанавливает связь по этому адресу (который является одним из двух адресов Сервера) и передаёт Серверу имя пользователя info.
  • Сервер определяет, что указано простое имя пользователя info и соединение установлено через адрес 192.0.0.2.
  • Сервер определяет, что этот IP адрес соответствует домену client1.com и добавляет имя этого домена к указанному простому имени.
  • Сервер формирует корректное полное имя пользователя info@client1.com.

Когда третий пользователь запускает своё клиентское приложение:

  • Клиентское приложение берёт указанный в настройке "сервер" client2.com и использует A-запись в DNS для того, чтобы преобразовать это имя в IP адрес 192.0.0.1.
  • Клиентское приложение устанавливает связь по этому адресу (который является одним из двух адресов Сервера) и передаёт Серверу имя пользователя info.
  • Сервер определяет, что указано простое имя пользователя info и соединение установлено через адрес 192.0.0.1.
  • Сервер определяет, что этот IP адрес соответствует Главному Домену и добавляет имя Главного Домена company.com к указанному простому имени.
  • Сервер формирует некорректное полное имя пользователя info@company.com.

Это происходит, потому что клиентское приложение (обычно - старый POP или IMAP почтовый клиент, FTP клиент и тому подобное) не передал информацию об имени "сервера", указанную в его настройках, и единственной информацией, которой располагал Сервер для определения полного имени аккаунта, был IP адрес соединения.

Чтобы решить эту проблему, третий пользователь должен указывать имя пользователя в виде info%client2.com, а не просто info. В этом случае, когда пользователь запускает своё клиентское приложение:
  • Клиентское приложение берёт указанный в настройке "сервер" client2.com и использует A-запись в DNS для того, чтобы преобразовать это имя в IP адрес 192.0.0.1.
  • Клиентское приложение устанавливает связь по этому адресу (который является одним из двух адресов Сервера) и передаёт Серверу имя пользователя info%client2.com.
  • Сервер определяет, что указанно полное имя пользователя info%client2.com и не обращает внимания на IP адрес. Он конвертирует символ % в символ @.
  • Сервер формирует корректное полное имя пользователя info@client2.com.

Обратите внимание: большинство FTP клиентов работает аналогично почтовым программам, использующим POP/IMAP и, в тех случаях, когда FTP пользователь не используют для установления соединения выделенный для его домена IP адрес, он должен будет указывать полное имя пользователя.

Обратите внимание:MAPI Коннектор всегда посылает полное имя пользователя: если пользователь указывает имя без знака @ или %, Коннектор добавляет к указанному имени знак '@' и значение, указанное в настройке Имя сервера.

Обратите внимание:XMPP клиенты отправляют имя 'домена пользователя' вместе с именем пользователя. Если указанное имя пользователя не содержит символов @ или %, то Сервер добавляет символ '@' и имя домена к имени пользователя.


Маршрутизация

После того, как полное имя пользователя сформировано, это имя (адрес) передаётся в Маршрутизатор.

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

Пример:
Пользователь с именем john имеет псевдоним john_smith;
все сообщения и сигналы, адресованные на адрес john_smith будут направляться пользователю john;
в клиентском приложении можно указывать как john, так и john_smith в настройке "имя пользователя" - в любом случае Сервер будет использовать пользователя с именем john.
Пример:
Пользователь john был переведён из главного домена company.com в домен client1.com, и был переименован в j.smith. Администратор создал правило маршрутизации (запись в Маршрутизаторе):
<john> = j.smith@client1.com;
все сообщения и Сигналы, адресованные на john@company.com будут посылаться в аккаунт j.smith в домене client1.com;
пользователь все ещё может указывать в своём клиентском приложении john в настройке "имя пользователя" и company.com в настройке "сервер" - но Сервер будет работать с ним как с пользователем j.smith в домене client1.com.
Обратите внимание:
не создавайте никакие правила маршрутизации (записи в Маршрутизаторе), которые перенаправляют пользователя postmaster Главного Домена. Вы можете оказаться не в состоянии управлять настройками Сервера, если имя пользователя postmaster перенаправлено в Пользователя, не обладающего необходимыми Правами администратора Master.
Если вы хотите, чтобы все сообщения и Сигналы для аккаунта Postmaster перенаправлялись бы на другой адрес, используйте для этого не Маршрутизатор, а Правила для пользователя postmaster.

Руководство CommuniGate® Pro. Copyright © 1998-2017, Stalker Software, Inc.