Обычно ChannelSet определяется группой каналов, которые определяют стратегию восстановления после отказа, а не как часть безопасной / незащищенной сегментации.
Смешение зашифрованных и незашифрованных каналов в одном наборе каналов на самом деле не имеет смысла.
Если для channelSet определено несколько каналов, клиент Flex попытается подключиться по первому и постепенно переключиться на следующий, а затем до следующего, пока не будет установлено соединение или все каналы не будут исчерпаны.
Если вы хотите, чтобы были определены как защищенные, так и небезопасные каналы, вы обычно определяете два набора каналов - по одному для каждого:
<s:ChannelSet id="channelSet">
<s:AMFChannel url="http://myserver:8080/myapp/messagebroker/amf" />
</s:ChannelSet>
<s:ChannelSet id="encryptedChannelSet">
<s:SecureAMFChannel url="https://myserver:8080/myapp/messagebroker/amf" />
</s:ChannelSet>
public function logon():void
{
// Credentials are passed via https
encryptedChannelSet.login("username","password");
}
Что не ясно из документации, так это то, что при условии, что channelSet
и encryptedChannelSet
являются частью одного и того же MessageBroker, состояние аутентификации и учетные данные пользователя доступны для обоих наборов каналов.
Т.е., хотя клиентский код предполагает, что учетные данные предоставляются только одному ChannelSet, на стороне сервера FlexContext
- это то, что содержит состояние аутентификации, которое связано с сеансом браузера, а не с конкретным каналом или ChannelSet.
Таким образом, после аутентификации encryptedChannelSet
, назначения, которые подвергаются действию channelSet
, которые защищены и требуют учетных данных пользователя, теперь доступны.