Я уверен, что вы можете смешивать файлы aspx и asp в одном веб-проекте. Итак, создайте web-proj, затем поместите в него файлы существующего сайта (из VS). Затем медленно начните рефакторинг существующего сайта в aspx, как вы можете, постранично, и, конечно, создайте новые страницы в формате aspx.
Использование IFRAME над этим подходом будет намного больше работы, чем можно ожидать. Но, несмотря на это, вы сталкиваетесь с проблемой двух несвязанных веб-сайтов, связанных с необходимостью доверять друг другу аутентифицированные сеансы, и это в первую очередь решается тем, что веб-сайты передают такую информацию друг другу в фоновом режиме, без непосредственного участия браузера , Вы должны иметь возможность изменять код на обоих сайтах (поэтому вы должны владеть обоими сайтами). Итак, если вы хотите пойти по этому пути, обычно это делается следующим образом:
Пользователь заходит на ваш сайт asp
Ваш сайт ASP вызывает веб-сервис на вашем сайте ASP.NET и сообщает ему, что пользователь будет приходить с конкретным одноразовым токеном в запросе и что ему следует доверять. Акценты здесь: веб-сервис должен быть хорошо защищен механизмом аутентификации (в противном случае вы рискуете получить серьезную проблему безопасности); упомянутый токен должен истечь после того, как он будет использован один раз и только один раз (в противном случае вы открываете свой сайт asp.net для злоупотреблений). Как правило, ваше приложение ASP вызывает службу ASP.NET с такой подписью: string GetAuthToken(string username). Приложение ASP.NET должно хранить эту информацию в виде записи в базе данных: имя пользователя, случайное и уникальное строковое значение (например, guid), время создания (с точностью не менее секунды) и используемое время.
Ваше приложение ASP получает одноразовый токен авторизации от приложения ASP.NET.
Ваше приложение ASP должно включить этот токен в URL-адрес, используемый во фрейме для страницы на сайте ASP.NET.
После этого ваше приложение ASP будет предоставлять браузеру страницу с рамкой.
Браузер начинает отображать страницу, затем он переходит к отображению фрейма на внешнюю страницу asp.net
Браузер запрашивает URL-адрес asp.net, содержащий токен авторизации
Сайт ASP.NET получает запрос и предполагает, что токен аутентификации присутствует и действителен;в противном случае исключение.Допустимый токен: никогда не используется (время используется в дБ, упомянутое в шаге 2) и действителен (его существование в дБ).Когда принимающая страница проверяет этот токен, она сразу же проверяет его как использованный.Лучше всего использовать эту логику как одну атомарную операцию (например, хранимую процедуру, если вы используете MS SQL Server).Таким образом, вы можете выполнить get-token и mark-token-used за один шаг.Этот URL должен быть анонимным;В любом случае вы должны иметь формы auth на этом сайте, и этот конкретный обработчик должен быть доступен любому пользователю.Если вам не нравится делать это исключение, то, возможно, создайте HttpModule, который будет проверять каждый запрос и действовать только на те, которые анонимны и содержат аутентификационный токен (проверяя токен, а затем, каксоответствующий, прерывая запрос или позволяя ему исполниться);Таким образом, вашей странице в рамке не нужно заботиться об аутентификации, но она также должна быть защищена с помощью форм.Я лично сделал бы это таким образом (модуль http).Кроме того, если вы уверены, что относительно короткий промежуток времени здесь пройдет между этапом 1 и этапом 2 (например, максимум несколько секунд), то do включает истечение токена в логике проверки токена (время проверки должно бытьне позднее, чем время создания токена + некоторое количество секунд, например, 30) - просто для дополнительной безопасности.В противном случае, если вы не реализуете истечение срока действия - представьте, что пользователь вошел в систему сегодня, который генерирует этот бесконечный токен, и злонамеренный пользователь каким-то образом захватил строку токена.Затем, если аутентифицированный пользователь никогда не посещал страницу с фреймом asp.net, токен будет пригоден для использования в дни, месяцы, годы с момента его выдачи, даже после того, как реальный пользователь закроет свою учетную запись.Вы не хотите этого риска.Если страница входа не перенаправляет на страницу с фреймом, вместо этого сделайте сервисный вызов с этой страницы (один раз за сеанс).В идеале срок действия токена должен истечь примерно через 30 секунд после его создания.
Если токен действителен, то часть приложения ASP.NET, проверяющая токен, будет нести ответственность за это.для выдачи форм-аутентичных куки.Вы найдете массу примеров там;ключевые слова: FormsAuthentication, создать cookie, аутентифицировать пользователя.Убедитесь, что помимо вставки файла cookie в ответ (что по умолчанию выполняется модулем FormsAuthentication), вы также немедленно задаете идентификатор этого текущего / конкретного запроса, так как до тех пор, пока вы его не сделаете, ваш запрос все еще считаетсяанонимный.Если вы этого не сделаете (и люди делают это, но я не думаю, что это необходимо), вам придется перенаправить этот запрос (что заставит браузер отправлять auth-cookie, который он только что получил в 302ответ).
Наконец, ваша страница в рамке получает одобрение, которое пользователь проверяет и может просматривать содержимое, которое генерирует эта страница.Ваша страница перенаправляет HTML в браузер, и браузер показывает, что содержимое во фрейме.
Обратите внимание, что вы не сможете иметь любойсвоего рода сценарии на стороне клиента (javascript), происходящие между страницей и фреймом (по соображениям безопасности), и это было бы еще одним способом, по которому я бы предпочел смешивать asp с файлами asp.net (и медленно обновлять часть asp до asp.нетто), если это имеет смысл в других аспектах, связанных с бизнесом.
Остерегайтесь проблем общего хостинга, связанных с исходящими запросами. Некоторые хосты блокируют весь исходящий трафик; поэтому, если ваше asp-приложение находится в такой среде, вы не сможете выполнить этот вызов веб-службы asp.net. Если у вас есть приложение asp, выполняющее другие / несвязанные http-вызовы через Интернет (например, оно общается со сторонними веб-службами), вы в порядке (оно будет работать); в противном случае проверьте это как-нибудь , так как вы никогда не можете быть уверены. Кроме того, даже если ваш сайт работает в вашей собственной среде, в компаниях часто используются исходящие брандмауэры, поэтому вам, возможно, придется запросить исключение для этого.
Помните, что обновление страницы не будет проблемой, и вам не нужно совершать вызов get-token более одного раза за сеанс аутентификации. Это связано с тем, что браузер после первой загрузки фрейма получит файл auth-cookie с сайта asp.net, и токен (даже если он присутствует в последующем URL-адресе фрейма) не будет проверен (помните, что модуль проверяет токен на анонимном только сеанс; см. шаг 8).
Подумайте об изменении настроек истечения срока действия файлов cookie между двумя сайтами. Представьте, что файл cookie аутентификации asp.net истекает до истечения срока действия файла cookie аутентификации asp: пользователь перезагружает страницу, и iframe показывает страницу входа на asp.net - безобразно. Таким образом, ваш файл cookie asp.net auth, вероятно, должен быть настроен так, чтобы он истекал дольше, чем файл cookie asp auth (как бы долго вы ни устанавливали его, вы не решите проблему, так как либо неправильно устанавливать cookie, чтобы он не истекал слишком долго время, например, 7 дней, или теоретически возможно, что пользователь вашего сайта asp будет просидеть все это время, не касаясь страницы фреймом после того, как он увидел ее один раз, и ваш файл cookie asp.net истечет). Итак, сделайте что-то вроде этого, возможно: установите для файла asp.net auth cookie срок действия через 20/30 минут (одним из них является значение времени ожидания по умолчанию). Затем приложение asp должно знать об этом значении тайм-аута. Итак, поправка к моему предыдущему заявлению об одном принятом вызове за сеанс. Вместо этого пусть asp вызывает сервис get-token каждый раз, когда вы знаете, что срок годности файла cookie asp.net уже истек или может истечь в ближайшее время. Другими словами, следите за тем, когда вы сделали последний вызов get-token для каждого пользователя, и если с момента последнего вызова get-token прошло 15 минут (например, когда срок действия cookie asp.net истекает через 20), сделайте его снова, измените URL фрейма, и фрейм будет аутентифицирован после истечения срока действия существующего файла cookie asp.net (который в этом примере будет составлять приблизительно 5 минут с этого момента).
Я продолжаю возвращаться, чтобы отредактировать этот ответ :) Итак, проблема с истечением срока действия cookie - при условии, что срок действия cookie asp.net истекает через 20 минут, и я сказал вам устанавливать URL на фрейм каждые 15 минут, а я также сказал вам: Заставьте токен истечь через 30 секунд, так что эти две вещи противоречат друг другу. Хм, интересно, какое здесь лучшее решение ... Может быть, установите, чтобы get-токен происходил ближе к истечению срока действия cookie asp.net (как, например, через 18 минут, но все же меньше, чем 20), и установите токен равным действителен, я не знаю, 3 минуты). Это привело бы к 18 + 3 = 21 для перекрытия истечения срока действия cookie asp.net. Все это потому, что у пользователя уже есть файл cookie asp.net. Итак, через 18 минут после того, как был выпущен первый файл cookie, они посещают страницу с фреймом, и страница решает получить еще один токен. Это запускает токен на сайте asp.net и устанавливает URL-адрес iframe с новым токеном. Но, поскольку существующий файл cookie asp.net по-прежнему действителен, новый токен даже не будет проверен (помните, что модуль проверяет только анон запросы с токеном? В противном случае у вас будет слишком много попаданий в БД, если вы будете делать это при каждом запросе), поэтому новый токен не будет использоваться немедленно. В конце концов, срок действия файла cookie asp.net истечет (через 2 минуты), и новый токен будет проверен. Если это проблема (если я пропустил какой-то вариант использования, который по существу приводит к странице входа в систему, отображаемой в рамке), то, возможно, вы можете реализовать какой-то другой механизм для сохранения этих файлов cookie: возможно, добавьте код на страницу входа в asp. net, чтобы найти токен в ReturnUrl (декодировать, затем загрузить в NameValueCollection, а затем искать его как обычный запрос строки запроса) и, возможно, сообщить обратно узлу asp что-то, что будет сигнализировать ему повторно запрашивать токен, когда приходит кадр назад (и что я имею в виду под этим, перенаправить страницу входа в систему, только в этом случае, обратно на специальный сценарий asp на сайте asp, который будет повторно запрашивать токен, а затем перенаправить фрейм обратно на asp.net с новым лексема.
Я же говорил, что будет много работы. Возможно, есть стандарт, который включает в себя все это. Проверьте OAuth (http://oauth.net/) и OpenID (http://openid.net/);). Эти методы аналогичны тем, что StackOverflow предлагает в качестве входа в систему, альтернативного учетным записям SO (Google, Yahoo и т. Д.). Однако это означает, что вы действительно отправляете пользователь, чтобы войти на сайт asp.net, затем вернуться на страницу, которая отображает контент с сайта asp.net. Возможно, вы можете объединить это с предложенным веб-сервисом вызовом (get-token ws, перенаправить верхнее окно с токеном в URL-адрес asp.net, asp.net будет аутентифицироваться и перенаправлять обратно, затем отобразится страница с фреймом.) Тем не менее, у вас все еще есть проблема с истечением срока действия файлов cookie, так как вам необходимо постоянно иметь возможность получать контент с сайта asp.net (тогда как Например, StackOverflow общается с Google от моего имени только один раз, во время входа в систему и никогда больше во время сеанса), но вместо того грязного пути перенаправления iframe, который я вам отправляю, возможно, вы можете просто повторить вход в систему в asp .net-site рутина каждые 15 минут (получить токен, перенаправить туда, проверить токен, перенаправить обратно). это каждые 15 минут на уровне всего сайта asp, с вами все будет в порядке - и пользователь даже не заметит этого в большинстве случаев, так как эти перенаправления будут быстрыми.
Извините, если это трудно читать. Надеюсь, это поможет. +1, если это так:)