Интеграция со сторонним веб-сайтом вызывает проблему проверки подлинности с помощью форм - PullRequest
0 голосов
/ 14 февраля 2009

Вот проблема. Я использую ASP.NET Forms Authentication для веб-сайта с типом баланса счета. Когда пользователь входит в систему, он может произвести оплату по своей учетной записи, перейдя на сторонний веб-сайт (3pw). Когда пользователь щелкает, чтобы сделать платеж, вот что происходит:

  1. Мой сайт делает запрос 3pw, передавая идентификатор.
  2. 3pw отправляет запрос на мой сайт, передавая идентификатор плюс идентификатор безопасности.
  3. Я проверяю вещи ....
  4. Случается больше вещей, о которых вам не нужно заботиться ...

Когда я тестирую этот процесс, я вижу в веб-журналах, что я попадаю на страницу одноразовых платежей на моем сайте. Используя что-то вроде Live HTTPHeaders, я вижу запрос к веб-сайту 3pw (шаг № 1). Затем в веб-журналах отображается запрос от 3pw на мой сайт (шаг № 2), но следующая запись в журналах - это новый запрос на страницу входа для моего сайта.

login.aspx?ReturnUrl=mypage.aspx

3pw не знает, как обрабатывать перенаправление на страницу входа в систему, а затем терпит неудачу. Вопрос в том, почему мой сайт считает, что пользователь больше не проходит аутентификацию, когда запрос поступает с 3pw на mypage.aspx? Я смотрел мои куки и куки, которые были созданы, когда я вошел в систему, все еще там. Разве это не говорит серверу, что я все еще аутентифицированный пользователь?

Вот что у меня есть в моем web.config

<authentication mode="Forms">
  <forms defaultUrl="~/somepage.aspx" 
     loginUrl="~/login.aspx"
         protection="All"
     timeout="30" 
     name="MyCookieName"
     enableCrossAppRedirects="true"
     requireSSL="true"/>
</authentication>

<location path="manage">
  <system.web>
    <authorization>
      <allow roles="UserRole" />
      <deny users="?" />
    </authorization>
  </system.web>
</location>

Прошедшие проверку пользователи находятся в роли UserRole. Страница, которую запрашивает 3pw, находится в каталоге Manage. 3pw не написан на .NET, и я не могу контролировать его конфигурацию.

Обновление:

Я прошу прощения, если я не настолько ясен, как мог бы быть. Позвольте мне повторить шаги.

  1. Пользователь заходит на мой сайт и проходит аутентификацию.
  2. Пользователь заходит на страницу однократного платежа на моем сайте.
  3. На странице одноразового платежа пользователь нажимает кнопку «Внести платеж».
  4. Кнопка «Внести платеж» отправляет запрос GET 3pw, передавая идентификатор в строке запроса.
  5. 3pw видит запрос и отправляет запрос POST на страницу подтверждения на моем веб-сайте.

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

Может быть, я не до конца понимаю весь процесс, но, так как запрос к 3pw, инициированный моим зарегистрированным пользователем, не будет ли подан мой запрос на мой сайт от 3pw?

Ответы [ 3 ]

0 голосов
/ 14 февраля 2009

Не могли бы вы уточнить, что вы подразумеваете под "запросом"? Если вы имеете в виду, что они буквально инициируют GET или POST-запрос со своего сервера на ваш, то Джон Раш прав: у них нет вашего файла cookie аутентификации. Если вы имеете в виду, что они перенаправляют на ваш сайт, то браузер аутентифицированного пользователя фактически делает запрос, и в этом случае кажется, что он должен работать.

Уточните пожалуйста ... спасибо!

0 голосов
/ 14 февраля 2009

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

пример разрешения ресурса быть незащищенным:

  <location path="accountPostback.aspx">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
0 голосов
/ 14 февраля 2009

Вы говорите, что сторонний веб-сайт делает запрос на ваш сайт (шаг 2)?

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

Edit:

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

Есть несколько способов исправить это, один из способов, как Дэниел Ожер предлагает вам открыть страницу accountPostback.aspx для всех. Это, вероятно, будет работать достаточно хорошо для вас.

Если вы хотите немного его заблокировать, я думаю, вы могли бы сделать что-то вроде этого (при условии, что у стороннего веб-сайта есть статический IP-адрес):

// In Global.asax...
void Authenticate_Request(object sender, EventArgs e)
{
    if (Context.Request.ServerVariables["HTTP_X_FORWARDED_FOR"] == System.Web.Configuration.WebConfigurationManager.AppSettings["ThirdPartyWebsiteIP"])
    {
        Context.User = new System.Security.Principal.GenericPrincipal(new System.Security.Principal.GenericIdentity("ThirdPartyWebsite"), new string[] {"AccountPostbackPermission"});
    }
}

и обновите приложение web.configНастройки:

<configuration>
  <configSections>
    <appSettings>
      <add key="ThirdPartyWebsiteIP" value="127.0.0.1" /> // edit this IP address to match the 3rd party's website's IP address
    </appSettings>
  <configSections>
<configuration>  

, а также авторизация:

<location path="manage">
  <system.web>
    <authorization>
      <allow roles="AccountPostbackPermission" />
      <deny users="?" />
    </authorization>
  </system.web>
</location>

Конечно, если сайт использует динамический IP-адрес, это не сработает, и вам придется просто разрешить всем посещать страницу.

...