If/When use "Azure Session State Provider (redis)" Нет необходимости использовать User.Identity.Name/IsAuthenticated?

Question

После того, как мы переехали на ферму Azure, я подразумеваю Azure Session State Provider (redis) для моего приложения asp.net mvc, но некоторые авторизированные страницы перенаправляют меня на страницу входа! Это потому, что я использую User.Identity.Name или User.Identity.IsAuthenticated в некоторых действиях! ли я заменить Пользователь.Идентичность.Имя с:

 // instead of below line 
     //Boolean usern = User.Identity.IsAuthenticated; 
     // is below lines : 
     Boolean usern = ""; 
     object objValue = Session["usersession"]; 
     if (objValue != null) 
      { usern = true;} 
     else {usern = false;} 

Является ли это право, если не то, почему пользователи перенаправлять войти еще раз иногда !!!

Answer 1

Я не думаю, что управление сеансом сделало бы это, независимо от Лазурного Редиса или иначе. Если вы используете cookie аутентификации asp.net, вам необходимо внести изменения в поддержку нескольких ролей.

Я знаю, что это старая статья, но если вы смотрите через Moving Applications to Microsoft Azure Cloud Services вы увидите следующее:

Существует еще одно изменение в приложение, которое потенциально влияет на процесс аутентификации. Если вы запустили приложение aExpense на нескольких экземплярах веб-роли в Azure, механизм шифрования cookie по умолчанию (который использует DPAPI) не подходит , потому что каждый экземпляр имеет другой ключ. Это означало бы, что файл cookie , созданный одним экземпляром веб-роли, не будет доступен для чтения еще одним экземпляром веб-роли . Чтобы решить эту проблему, вы должны использовать механизм шифрования файлов cookie , в котором используется ключ, общий для всех экземпляров веб-роли . Следующий код из файла Global.asax показывает, как заменить объект SessionSecurityHandler по умолчанию и настроить его на , используя класс RsaEncryptionCookieTransform.

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

Answer 2

Это, вероятно, не проблема сеанса, а проблема с cookie-файлом аутентификации. У Azure, скорее всего, балансировка их серверов сбалансирована, даже если вы используете только один экземпляр/роль (это дает им надежность%). Это означает, что ваше приложение фактически существует более чем на одном сервере за раз.

MachineKey в приложении .NET - это то, что отвечает за шифрование и дешифрование вашего файла cookie для проверки подлинности. В вашем web.config, если вы неправильно определяете атрибут <machineKey>, IIS составляет для вас машинный ключ. Каждый сервер, на котором запущено приложение, будет создавать свой собственный машинный ключ, если он не определен вами. В результате один сервер может расшифровать и прочитать ваш билет аутентификации, в то время как следующий запрос отправляется на другой сервер, который не может расшифровать билет проверки подлинности, поскольку он был зашифрован другим ключом, и этот сервер считает, что вы не вошли в систему.

Чтобы устранить эту проблему, откройте файл web.config и определите свой атрибут <machineKey> и переустановите его. После входа в систему с недавно развернутым приложением вы увидите, что эта проблема исчезнет.

Forms authentication and Machine Key information on MSDN

Machine Key Generator