aspnet-Identität ungültiges token auf der Bestätigungs-E-Mail

Ich versuche, um zu bestätigen Sie ein Konto, aber ich bin immer "invalid token." angezeigt.

Hier ist, was ich versuche:

var code = await UserManager.GenerateEmailConfirmationTokenAsync(user.Id);
var callbackUrl = Url.Action("ConfirmacaoEmail", "Usuario", new { userId = user.Id, code = code }, protocol: Request.Url.Scheme);

await UserManager.SendEmailAsync(user.Id, "Ativação de Conta", user.GetEmailAtivacao(model.Nome, callbackUrl));

wenn ich den Anruf UserManager.ConfirmEmailAsync nach diesem code, kann ich das bestätigen-account. Allerdings, wenn ich den link zu öffnen, dass es in der variable callbackUrl und versuchen Sie, um zu bestätigen, durch diese Aktion, ich bin immer der Fehler.

Dachte ich, es könnte etwas mit OwinContext, also habe ich beschlossen zu nennen HttpContext.GetOwinContext().GetUserManager<MyCustomUserService> aber ich bin immer der gleiche Fehler.

Irgendwelche Hinweise?

  • In meinem Fall (Asp.Net Core 3.0) es scheint, dass die eingerüstet Seiten führte zu diesem Fehler. Siehe mein Antwort hier.
InformationsquelleAutor Thiago Custodio | 2014-12-17
  1. 24

    Wahrscheinlich, dass der code in transit geändert durch browser. Versuchen Sie dabei UrlEncode auf den token:

    var code = await userManager.GenerateEmailConfirmationTokenAsync(userId);
code = System.Web.HttpUtility.UrlEncode(code);

    Sonst browser patzt mit der speziellen Symbole, die vorhanden sein können in der token.

    • Ich weiß nicht, warum, aber ich habe gewechselt von der POST zu BEKOMMEN und es funktioniert.
    • was bedeutet, dass Sie haben, ändern sich von POST zu BEKOMMEN, was und wo? Bitte genauer zu sein, anderen Menschen zu helfen...
    • Es gab ein problem mit der Bestätigungs-token. Wenn ich mich an die Aktion mit der POST, der code hat nicht funktioniert. So, ich habe mich verändert den code, um die Aktion mit zu BEKOMMEN-und es funktionierte. Für mich macht es keinen Sinn, aber ich konnte das problem lösen, mit dieser kleinen änderung.
    • Danke. Ja ich kann nicht viel Sinn darin, mir auch!!!! BTW nach kämpfen, auf die es für die Stunden, die ich entdecken, dass mein Token Ungültig wurde dued durch verschiedene app-Namen in Microsoft.Owin.Sicherheit.DataProtection.DpapiDataProtectionProvider(...appName) in der ApplicationUserManager.Create () - Methode.
    • Ich hatte, um UrlDecode(code), um die ConfirmEmail Aktion für diese zu arbeiten.
    • UrlDecode kann benötigt wurden für eine frühere version, aber das hinzufügen der UrlDecode brach es für mich in MVC5.2.3. Der code wird automatisch entschlüsselt, und Sie tun es wieder eingeführt Unterschiede.
    • Das kann noch Probleme verursachen, weil das token enthält '/', die kann mess up-routing.
    • Die Url-Codierung konvertiert / in %2F
    • Ja, aber dies betrifft angular-routing, zum Beispiel. Base64 ist der Weg.
    • Token kommt in Base64 aus dem Rahmen. Noch Base64, können enthalten Symbole + und / (faqs.org/rfcs/rfc4648.html Blättern Sie zu "Tabelle 1: Die base64-Alphabet") - beide haben eine Besondere Bedeutung in URI. Daher müssen Sie die url-codieren
    • Es sei denn, du redest Base64Url. Aber token kommt immer noch in standard-Base64-und Sie müssen noch zu tun ist, Operationen zu machen, URL-sicher.
    • Ja, ich meinte bas64 für die url. HttpUtility.UrlEncode würd token enthält Schrägstriche (als %2F) und diese stören, routing, wenn Sie es verwenden, um generieren eine URL im format /x/y/:token.
    • in diesem Fall ist die Lösung verdient eine separate Antwort. Ich schlage vor, Sie schreiben Sie es auf und bekommen einige upvotes -)
    • Serdar Çatalpınar die Antwort liefert die Lösung, die sich mit dem problem befasst 🙂

    InformationsquelleAutor trailmax
  2. 22

    Ich erlebt haben das gleiche problem. Ich löste das problem durch den folgenden code.

    Beispiel: 

    var emailToken = _customManager.GenerateEmailConfirmationToken(userId);
emailToken = emailToken.Base64ForUrlEncode();

    Erweiterung Methoden => Namensraum : System.Text,System.Web

    public static class UrlEncoding
{
        public static string Base64ForUrlEncode(this string str)
        {
            byte[] encbuff = Encoding.UTF8.GetBytes(str);
            return HttpServerUtility.UrlTokenEncode(encbuff);
        }

        public static string Base64ForUrlDecode(this string str)
        {
            byte[] decbuff = HttpServerUtility.UrlTokenDecode(str);
            return Encoding.UTF8.GetString(decbuff);
        }
}
    InformationsquelleAutor Serdar Çatalpınar
  3. 2

    Serdar Lösung war der Schlüssel zu der Lösung für Leerzeichen und + simbols mit Eckig als web-client-Anwendung.

    Aber manchmal war ich auch immer zufällig "invalid token" - Fehler. Nach einigen Abfragen, um die Benutzer-Datenbank habe ich gefunden, dass diese Fehler wurden nur jene Benutzer, die Leerzeichen o Bindestriche in Benutzernamen.

    Lösung war, konfigurieren Sie den Benutzer-Manager zu ermöglichen, diese Zeichen in Benutzernamen. Wollte sagen, dass mein Benutzer-Datenbank migriert wurde von Druppal direkt an SQL Server und viele von denen, die Benutzer vermieden die default policy UserValidator auf Benutzer-Manager.

    Finden Sie, wie zu konfigurieren, die UserValidator zu zulassen, die nicht-alphanumerische Zeichen am Ende von diesem thread:

    Asp.NET - Identität 2 - Invalid-Token Fehler

    InformationsquelleAutor Josep Alacid
  4. 2

    Ok, das Stunden, Nein, Tage meines Lebens. Nach dem Versuch alle anderen Vorschläge in diesem thread ein Asp.NET - Identität 2 - Invalid-Token Fehler ich fand, dass anstelle von aufrufen 

    await SignInManager.SignInAsync(user, isPersistent: false, rememberBrowser: false);

    in der Register-Methode nur vor der GenerateEmailConfirmationTokenAsync-block

    await SignInAsync(user, isPersistent: false);

    genannt wurde, ist definiert als

    private async Task SignInAsync(ApplicationUser user, bool isPersistent)
{
        AuthenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie);
        AuthenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = isPersistent }, await user.GenerateUserIdentityAsync(UserManager));
}

    Ich denke, dass dieses verursacht wurde durch das Gerüst, das die Anwendung mit einem älteren ASP.Net MVC-Version. Die beschriebene Methode kann gefunden werden in http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity von 2013.

    InformationsquelleAutor ben
  5. 0

    Falls diese Lösungen nicht für Sie arbeiten - lief ich in das problem Asp.Net Kern-Projekt, da habe ich die folgende Konfiguration im Startup.cs:

    services.Configure<RouteOptions>(options =>
{
  options.LowercaseUrls = true;
  options.LowercaseQueryStrings = true;
});

    Die zweite Einstellung war, die den Bestätigungs-code in Kleinbuchstaben umgewandelt, was verursachte, dass die Validierung fehlschlägt. Im Idealfall würde ich mag zu halten query-string-Parameter Kleinschreibung, und nicht ändern, die query-string-Werte, aber ich bin nicht der Suche nach einem Weg, das zu tun, so dass ich nur entfernt den Abfrage-string-Einstellung:

    services.Configure<RouteOptions>(options =>
{
  options.LowercaseUrls = true;
});
    InformationsquelleAutor DanO
Schreibe einen Kommentar