WCF: Асинхронные вызовы более безопасны?

Question

В проекте, в котором я сейчас работаю, мы используем WCF.Политика компании вынуждает нас использовать асинхронные вызовы, и причина должна быть в безопасности.Я спросил, почему это намного безопаснее, но я не получаю четких ответов.

Может кто-нибудь объяснить, почему это так безопасно?

Answer 1

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

Единственный способ, которым кто-то может быть смущен, думая, что асинхронные вызовы более "безопасны /безопасный », они думают, что необработанные исключения WCF не приведут к остановке основного потока, если они асинхронные, так как они будут вызваны внутри обратного вызова.

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

Answer 2

Простое предоставление операции WCF с использованием асинхронной подписи (BeginBlah / EndBlah) фактически не влияет на отображаемую операцию. При просмотре метаданных такая операция, как

[OperationContract(AsyncPattern=true)]
IAsyncResult BeginSomething(AsyncCallback, object)

void EndSomething(IAsyncResult)

... на самом деле все равно в конечном итоге представляется как операция под названием «Нечто». И на самом деле это одна из приятных вещей в WCF: клиент и сервер могут различаться в зависимости от того, хотят ли они выполнять / использовать операцию синхронно.

Так что, если вы используете генерацию прокси WCF (например, через Add Service Reference), вы получите синхронные версии каждой операции независимо от того, реализованы они асинхронно или нет , если вы не отметите маленькую галочку для генерации асинхронного перегрузки. И когда вы это делаете, вы получаете асинхронные версии операций, которые могут быть объявлены только синхронно на сервере.

Все, что делает WCF на клиенте и на сервере, дает вам выбор модели потоков: хотите ли вы, чтобы WCF дождался результата, или вы собираетесь сообщить ему, что вы закончили. Насколько мне известно, то, каким образом осуществляется фактическое транспортное сообщение, совершенно не зависит. Например: для NetTcpBinding сокет все еще остается открытым на время вызова, в любом случае.

Итак, чтобы добраться до сути, я действительно изо всех сил пытаюсь представить, как это могло бы иметь какое-либо значение для защитной оболочки службы WCF. Если сервис предоставляется с использованием асинхронного шаблона и действительно реализован асинхронным способом (асинхронный для исходящего ввода-вывода, или очереди работают через пул потоков или что-то в этом роде), то, вероятно, есть аргумент, что усложнить DOS для службы будет труднее (путем исчерпав пул потоков WCF IO), но это было бы об этом.

См. Синхронные и асинхронные операции в MSDN

Примечание: если вы разделяете интерфейс контракта между клиентом и сервером, то, очевидно, синхронность двух концов совпадает (потому что они оба используют один и тот же тип интерфейса), но это всего лишь ограничение используя общий интерфейс. Если бы вы создали другой эквивалентный интерфейс, отличающийся только асинхронным шаблоном, вы все равно могли бы создать ChannelFactory для него просто отлично.

Answer 3

Я согласен с другими ответами - определенно не более безопасными.

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

Кстати, Fiddler - отличный инструмент.Это открывает глаза на то, какие данные и сколько данных вы отправляете на сервер.

Answer 4

Нет, они не более или менее безопасны, чем синхронные вызовы.Единственное отличие состоит в том, что клиент ожидает ответа на синхронные вызовы, тогда как в асинхронном режиме он уведомляется об ответе.

Они приходят с той точки зрения, что синхронные вызовы оставляют соединение открытым дольшеили что?

Answer 5

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