Ho appena scaricato un VS 2012 insieme a ASP.NET 4.5 e MVC 4.0 e stavo dando dei calci alle gomme con un'app campione e ho scoperto che l'autenticazione dei moduli funziona perfettamente con ASP.NET 4.0/MVC 3 sembra non funzionare più con l'ultima versione.L'autenticazione di moduli ASP.NET 4.5/MVC 4 non riesce
Quando faccio una chiamata alla funzione di login nel controller di azione, la chiamata non riesce WebSecurity.Login:
public ActionResult Login(LoginModel model, string returnUrl)
{
if (ModelState.IsValid && WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe))
{
return RedirectToLocal(returnUrl);
}
// If we got this far, something failed, redisplay form
ModelState.AddModelError("", "The user name or password provided is incorrect.");
return View(model);
}
ho sostituito questo codice con l'equivalente in mia fonte VS 2010, e che anche fallisce (usando la ormai obsoleta funzione FormsAuthentication.Authenticate).
La mia domanda è: qualcuno ha effettuato il porting di un'app MVC3 a MVC4 e ha trovato una soluzione alternativa a questo problema? Sto usando IIS Express, quindi suppongo che potrebbe causare qualche problema in qualche modo, ma se hai qualche idea, lo apprezzerei.
ho copiato la mia configurazione dal mio asp.net lavoro 4/MVC3 app come segue, ma senza fortuna (ecco le parti rilevanti):
<connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=tcp:sql2k1201.dbprovider.net;Initial Catalog=SQL2012_db;User ID=SQL2012_db_user;Password=dbpassword;" providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="2880"/>
</authentication>
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="DefaultConnection"
enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
applicationName="/" />
</providers>
</membership>
<profile>
<providers>
<clear/>
<add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="DefaultConnection" applicationName="/" />
</providers>
</profile>
<roleManager enabled="true">
<providers>
<clear/>
<add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="DefaultConnection" applicationName="/" />
</providers>
</roleManager>
Pranav - grazie per aver segnalato quell'articolo. Ho notato che un sacco di commenti sull'articolo dicevano che i nuovi provider erano tutt'altro che semplici e che non esiste un percorso di migrazione regolare se si desidera convertire i membri/ruoli esistenti nel nuovo schema. Mi sembra che mentre loro hanno tentato di semplificare un sistema complesso, lo hanno reso ancora di più, e solo provando le nuove cose apportando una rapida modifica al web.config si ottengono nuove tabelle che non funzionano con il impostazione precedente. Ne ho di più da imparare di sicuro! –