Проблема доступа к одному сайту с другого через URL-адрес с ограниченным доступом - PullRequest
Новая
       81

Проблема доступа к одному сайту с другого через URL-адрес с ограниченным доступом

1 голос
/ 19 января 2020

У меня есть два сайта, оба в разных доменах. Так, например, http://example1.com и http://example2.com. Оба сайта находятся в ASP. NET и используют проверку подлинности с помощью форм. Пользователям example1.com требуется доступ к определенным ресурсам example2.com без необходимости иметь учетные записи в example2.com. Таким образом, всякий раз, когда пользователю example1.com требуется доступ к ресурсу в example2.com, создается временный URL-адрес, через который пользователь может получить доступ к ресурсу. URL-адрес - это ограниченный период времени для однократного использования, который становится недействительным после первого использования. Вот как это работает.

  1. Когда сайт example1.com должен получить доступ к ресурсу на сайте example2.com, в строке запроса появляется response.redirect с зашифрованным токеном в строке запроса. например, http://example2.com/path/resource1/?token= encryptedToken
  2. Этот токен читается на стороне example2.com, и если он действителен, для проверки подлинности форм устанавливается значение "temp user". «Temp User» - это пользователь с ограниченным доступом, созданный специально как прокси для пользователей example.com.

Ниже приведен код для достижения этого в событии Application_AuthenticateRequest 

protected void Application_AuthenticateRequest(object sender, EventArgs e)
{   
    const string TempUser = "TempUser";
    if (!Request.IsAuthenticated)
    {                
        var url = Request.Url;              
        var token = Request.QueryString["token"];

        if(IsKnownUrl(url) && IsValidToken(token))
        {
            FormsAuthentication.SetAuthCookie(TempUser, false);
            Response.Redirect(Request.RawUrl);
        }
    }
}

private bool IsKnownUrl(string url){

    //Logic to check the url is from known sources
}

private bool IsValidToken(string token){

    //Logic to token is valid and not expired
}

Это работало нормально, пока оба сайта не были переведены на SSL. т.е. https://example1.com и https://example2.com. и это перестало работать. Response.Redirect с example1.com на example2.com переходит в 302 l oop, что означает, что по какой-то причине повар аутентификации ie не установлен или не принят. Когда я просматриваю сетевую активность в Chrome Инструментах разработчика браузера, я вижу следующий след

Имя статуса

https://example2.com/path/resource1/?token= encryptedToken 302

https://example2.com/path/resource1/?token= encryptedToken 302

https://example2.com/path/resource1/?token= encryptedToken 302

..................

Наконец браузер сдается и показывает, что страница перенаправляется слишком много раз.

Есть идеи, что может быть не так?

1 Ответ

0 голосов
/ 22 января 2020

Спасибо Айдын за ваш совет. Для тех, кто также сталкивается с подобной проблемой, вот решение.

  • После проверки с помощью Fiddler я обнаружил, что файлы cookie аутентификации (.ASPXAUTH) отправлялись с сервера, но браузер не отправлял их при последующих запросах.
  • Кроме того, URL-адреса example2.com отображались в example1.com внутри IFrame. После некоторых поисков я обнаружил, что для IFrames браузер будет отправлять куки, только если в заголовке ответа Set-Cook ie указано "SameSite = None" .

Итак в конце концов мне пришлось обновить свой код, чтобы создать ASPXAUTH cook ie вручную, поскольку cook ie, созданный классом FormsAuthentication, устанавливает его в "Lax".

...