Безопасность Asp.Net Webforms - нарушает переход приложения на .Net 4 - PullRequest
Новая
       26

Безопасность Asp.Net Webforms - нарушает переход приложения на .Net 4

0 голосов
/ 18 января 2011

Я переместил приложение из WebForms в .Net 3.5 в .Net 4. Единственное изменение было в web.config для удаления расширений 3.5, так как они теперь являются частью .Net 4.

У меня есть следующий тег апплета (элемент управления JUpload программного обеспечения) на сайте, защищенном с помощью FormsAuthentication и пользовательским принципалом: 

<APPLET 
    id="UploadCtl"
    CODE="persits.transfer.gui.UploadUI.class" 
    ARCHIVE="JUpload.jar" 
    WIDTH="99%" HEIGHT="200" 
    NAME="JUpload" MAYSCRIPT="yes"
    >
        <PARAM NAME="cabbase" VALUE="JUpload.cab" />
        <PARAM NAME="UseSockets" VALUE="false" />
        <param name="DNDOverrideEnabled" value="true" />
        <PARAM NAME="ShowTransferButton" VALUE="false" />
        <PARAM NAME="AllowAddFiles" VALUE="true" />
        <param name="AllowRemoveFiles" value="true" />
        <param name="UploadURL" value="/site/manageDocumentsPost.aspx" />
        <param name="FinalURL" value="/site/manageDocuments.aspx" />
        <PARAM NAME="DebugInformation" VALUE="true">
        <param name="MaxFileSize" value="2500" />
        <PARAM NAME="Cookie1" VALUE="ASP.NET_SessionId=<% =SessionId %>">
        <PARAM NAME="Cookie2" VALUE="<%=FormsCookieName %>=<%=FormsCookieValue %>">
</APPLET>

В основном элемент управления будет публиковать URL-адрес, указанный в UploadURL.Два параметра cookie используются для обеспечения того, чтобы пользовательский SessionId и FormsAuthTicket отправлялись апплетом загрузки при выполнении публикации.

Как я уже говорил, это прекрасно работает в .Net 3.5 (CLR 2.0).Переходя к .Net 4, CLR4, кажется, что происходит то, что запрос /site/ManageDocumentsPost.aspx перенаправляется на страницу входа, и затем элемент управления отображает это, предполагая, что загрузка прошла нормально.Хотя страница поста никогда не выполняет свой код (и пост не должен ничего возвращать, что заставляет элемент управления запрашивать FinalUrl).

Используя Fiddler, я вижу, что manageDocumentsPost вызывает перенаправление, и это перенаправление имеетдругой SessionId Asp.Net.

Есть идеи, что могло бы измениться, чтобы вызвать это?Что еще более важно, есть идеи, чтобы он снова заработал?

Спасибо, Энди

1 Ответ

0 голосов
/ 26 января 2011

Хорошо, я выяснил, как заставить это работать.

ранее я сохранял принципала в сеансе и загружал в событие AquireSessionState.

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

В событии AuthenticateRequest, если пользователь аутентифицирован, я могу легко найти фактического принципала и получить его из кэша.По какой-то причине, хотя элемент управления вызывает событие, не прошедшее проверку подлинности, но сеанс и formsauthcookie присутствуют в запросе.Я расшифровываю куки-файл auth, а затем снова использую информацию в билете, чтобы найти принципала.

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

Надеюсь, это поможет кому-то еще.

...