лучший способ обмена данными типа «состояние сеанса» между двумя приложениями .net

Question

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

мы создали новый проект, он наследует global.asax основного проекта, а также просто прекрасно обращается к web.config основного проекта, однако в глобальном коде asax есть сессия, проверяющая целостность данных, чтобы увидеть если пользователь вошел в систему .. это то, где у нас возникают проблемы .. пользователь вошел в систему, но сайт выдает ошибку, заявив, что он вошел в систему, потому что проект расширения не может получить доступ к идентификатору пользователя сеанса, который установлен основной проект.

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

также мы не хотим идти по пути мьютексов ... хотим держаться подальше от оконного кодирования, если сможем ...

план сайта о том, что происходит с сеансом: пользователь входит в систему с помощью кода asp (код .net 1.1) пользователь проходит проверку подлинности и успешно вошел в систему, отправляет guid для этого пользователя в базу данных, основной проект (код .net 2.0) получает этот guid, получает данные пользователей и сохраняет идентификатор пользователя в сеансе. любая страница, для которой необходимо знать, кто пользователь, получает ее из сеанса («идентификатор пользователя»)

так: мы создаем еще один проект, который наследует global.asax, может получить доступ к web.config - DONE!

что мы хотим сделать поверх этого: этот новый проект должен содержать страницу (функция добавления из основного проекта) иметь эту страницу для доступа к сеансу («идентификатор пользователя»), установленному из основного проекта. - НЕ УВЕРЕН, КАК ЭТО СДЕЛАТЬ ...

Answer 1

Я бы поставил перед моим предложением префикс, сказав, что лучший способ свести к минимуму сложность - это использовать сервер состояний . Это проблема, для решения которой они предназначены.

Это было сказано ...

Поскольку два приложения должны запускаться в разных процессах (как и в разных версиях среды выполнения), они не могут напрямую обмениваться данными.

Одним из вариантов может быть использование веб-служб или Remoting . Вы можете иметь объект CustomSession, в котором хранятся все данные сеанса, и идентифицировать каждый из них по Guid . Вы можете отслеживать все существующие сеансы, созданные в приложении A с помощью Guid-CustomSession, и передавать Guid через строку запроса в приложение B. Приложение B может запрашивать приложение A с помощью Guid через веб-службу или удаленное взаимодействие и возвращать соответствующий объект CustomSession. , Вы можете сделать то же самое в обратном направлении.

Единственная проблема здесь заключается в том, что вы должны убедиться, что Guid всегда указывается в URL при переходе от страницы в приложении A к странице в приложении B или наоборот. Приложение всегда может проверить, существует ли сессия, чтобы вернуться к использованию Guid, чтобы увидеть, есть ли у другого приложения сессия.

Имейте в виду, что некоторые структуры данных .NET (не многие) по-разному сериализуются между .NET 1.1 и 2.0, поэтому при совместном использовании объектов через удаленное взаимодействие или веб-службы вам может потребоваться учитывать это.

Answer 2

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

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

Answer 3

Я знаю, что вы сказали, что хотите держаться подальше от Session State Server ....

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

Но опять же, чем бы вы ни занимались, чтобы делиться данными сеанса, точно так же, как указывал другой постер "Рекс М", вам нужно быть осторожным с тем, каким типом данных сеанса вы делитесь и что его нужно сериализовать -able.

Answer 4

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

Answer 5

Рекс М: мы пытаемся обмениваться данными сеанса между одними и теми же версиями .net .. обе работают под управлением .net 3.5 ((на платформе .net 2.0), у нас уже есть код для передачи данных для входа в систему 2.0.

у нас работает основной проект, однако мы хотим добавить в него модули, мы подумали просто: если вы добавляете другое веб-приложение .net, не используете пространства имен и настраиваете сервер состояний сеанса, настройте ваши ссылки , а затем скомпилировать, все будет соусом ..

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

Есть ли что-нибудь, что мы можем сделать, чтобы это работало?

(без использования сервера состояний sql).

Answer 6

Вы можете использовать куки для хранения вашего UserID. И ваши приложения 1.1 и 2.0 могут получить к нему доступ без каких-либо проблем.