2008-10-14 2 views
3

У меня есть апплет Java, который выполняется внутри страницы aspx, прошедшей проверку подлинности. В версии .NET 1.1 моего сайта апплет имеет доступ к файлу сеанса и может извлекать файл с сервера, но в версии .NET 2.0 он не может пройти проверку подлинности.Совместное использование cookie сеансов ASP.NET с апплетом Java

Я видел пару сообщений на форуме в другом месте, в которых говорится, что 2.0 устанавливает файлы cookie для HttpOnly по умолчанию, но предоставленные решения пока не сработали. Я также читал, что 2.0 может быть дискриминирующим на основе user-agent.

У кого-нибудь есть опыт или понимание этого?

ответ

5

Этот вопрос старый, но я подумал, что было бы полезно иметь правильный ответ здесь.

Filip запутанная серверная Java с клиентской Java. Он прав, что вы не можете передавать сеансы между двумя серверными платформами, такими как Java (J2EE) и ASP.Net, без использования специального подхода.

Однако апплеты являются клиентскими и поэтому должны иметь доступ к информации о сеансе на главной странице. Проблема в том, что ASP.Net 2.0 добавил флаг HttpOnly в файлы cookie сеанса. Этот флаг запрещает JavaScript и Java-апплеты получать доступ к этим куки.

Обходной способ заключается в отключении флага HttpOnly на сессионных файлах cookie. В то время как вы можете быть в состоянии сделать это в конфигурации в новых версиях ASP.Net, в предыдущих версиях решение было добавить следующий код в ваш Global.asax файл:

protected void Application_EndRequest(object sender, EventArgs e) 
{ 
    /** 
    * @note Remove the HttpOnly attribute from session cookies, otherwise the 
    *  Java applet won't have access to the session. This solution taken 
    *  from 
    *  http://blogs.msdn.com/jorman/archive/2006/03/05/session-loss-after-migrating-to-asp-net-2-0.aspx 
    * 
    *  For more information on the HttpOnly attribute see: 
    * 
    *  http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/aspnet.aspx 
    *  http://msdn2.microsoft.com/en-us/library/system.web.httpcookie.httponly.aspx 
    */ 
    if (Response.Cookies.Count > 0) 
    { 
     foreach (string lName in Response.Cookies.AllKeys) 
     { 
      if (lName == FormsAuthentication.FormsCookieName || 
       lName.ToLower() == "asp.net_sessionid") 
      { 
       Response.Cookies[lName].HttpOnly = false; 
      } 
     } 
    } 
} 

Обратите внимание, что даже с этим исправлением , не все комбинации браузера/ОС/Java могут обращаться к файлам cookie. В настоящее время я изучаю проблему с кукисами сеансов, которые не доступны в Firefox 4.0.1 с Java 1.6.0_13 в Windows XP.

Обходной путь заключается в использовании подхода, предложенного доктором Дадом, где идентификатор сеанса передается апплету в качестве параметра, а затем либо внедряется в URL-адрес запроса (для включения URL-адресов в сервер- боковая конфигурация) или отправлено в виде файла cookie, настроенного вручную.

0

Ответ Филипа не совсем корректен. Я запустил программу, чтобы обнюхать заголовки HTTP на моей рабочей станции, а апплет Java действительно представляет собой аутентификационный билет ASP.NET в некоторых случаях - просто недостаточно надежен для моих нужд.

В конце концов я нашел решение, но это не полностью решило мою проблему. Вы можете добавить запись в web.config в .NET 2.0: <httpCookies httpOnlyCookies="false" />; но это не сработало для всех моих пользователей.

Долгосрочное решение оказалось модификацией апплета Java, так что ему не нужно ничего извлекать с веб-сервера.

1

Filip является верным и неправильным, по крайней мере, для Java и ASP.NET. Апплет может получить доступ к сеансу ASP.NET путем обмана. В моем случае мы добавили идентификатор сеанса в качестве параметра в апплет, который апплет затем добавляет в виде файлов cookie в свои запросы. Кажется, работает нормально. (Мы зашифровали идентификатор сессии, чтобы сорвать эти неприятные хакерские фолы!)

0

Я знаю, что это может быть очень поздний ответ, но я могу дать вам более простое решение: - обычно не всегда апплеты используют html и javascript для взаимодействия и взаимодействия. - Javascript запускается в браузере. - Ajax звонки сделаны браузером. - Ajax-вызовы асинхронны и могут быть легко интегрированы в логику апплетов.

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

Смежные вопросы