В данном случае (пример с форумом) серверу невозможно определить момент окончания моей сессии, поскольку только я сам могу решить, писать в эту тему или уже хватит. И растёт эта неопределённость из того факта, что используемый форумом протокол - stateless в своей природе. Так что сессия в этом понимании - ни что иное, как некая достаточно близкая апроксимация, реализованная доступными в протоколе методами. Стало быть, пример не совсем корректен.MarkM писал(а):[trn]
Nu i chto, chto SOAP protokol'no nezavisimyj. Mozhno sdelat' solid-sessiju i na stejtless protokole. Tomu primer eta konfa - tred eto kak by sessija, my obmenivaemsja messagami v kontekste etoj sessii.
[/trn]
И, поскольку все протоколы, на которых может паразитировать SOAP, являются также stateless, все решения, которые будут найдены, останутся только лишь апроксимацией.
Socket тут тоже не будет идеальным решением, поскольку TCP соединение тоже может рваться. Ты что-же, будешь требовать reauthentication после каждого обрыва связи?
Я намекаю на то, что вряд ли данная проблема может быть решена в рамках сетевого транспорта. По логике - это относится к application domain. Другими словами - твоя личная, как разработчика, головная боль. Не зря существует отдельная сущность, такая, как authentication ticket.
Кстати, и с сокетом тоже не всё просто. Ты хочешь обмен данными также вести по SSL? Если нет, тогда и socket тебя не спасёт, поскольку придётся устанавливать два физическиз соединения.
Если да, то только в этом случае ты можешь более-менее защититься от replay или man-in-the-middle.
Ну и можешь начать готовиться к тому, что некоторые сервера могут принудительно разрывать соединение после ответа на HTTPS request.
Я тебя, конечно, понимаю. Выбирать в конечном счёте тебе. Я никакой из методов защищать не собираюсь. Просто позднее может оказаться, что об изначальном выборе более сложного в реализации метода начинаешь жалеть. Когда уже достаточно поздно, в полном соответствии с.
