Was verursacht diese "Ungültige Länge für ein Base-64-Zeichen-Array"?

Ich habe hier sehr wenig zu tun. Ich kann dies nicht lokal reproduzieren, aber wenn Benutzer den Fehler erhalten, erhalte ich eine automatische Benachrichtigung über E-Mail-Ausnahmen:

Invalid length for a Base-64 char array.

  at System.Convert.FromBase64String(String s)
  at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
  at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState)
  at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
  at System.Web.UI.HiddenFieldPageStatePersister.Load()

Ich bin geneigt zu glauben, dass es ein Problem mit Daten gibt, die viewstate zugewiesen werden. Beispielsweise:

List<int> SelectedActionIDList = GetSelectedActionIDList();
ViewState["_SelectedActionIDList"] = SelectedActionIDList;

Es ist schwierig, die Fehlerquelle zu erraten, ohne den Fehler lokal reproduzieren zu können.

Wenn jemand Erfahrung mit diesem Fehler hat, würde ich wirklich gerne wissen, was Sie herausgefunden haben.

Ich habe diesen Fehler gesehen, der durch die Kombination eines großen Ansichtszustands und über aggressiver Geräte / Firewalls zum Filtern von Inhalten (insbesondere im Umgang mit K-12-Bildungseinrichtungen) verursacht wurde.

Wir haben es umgangen, indem wir Viewstate in SQL Server gespeichert haben. Bevor Sie diesen Weg gehen, würde ich empfehlen, die Verwendung von viewstate einzuschränken, indem Sie nichts Großes darin speichern und es für alle Steuerelemente deaktivieren, die es nicht benötigen.

Referenzen zum Speichern von ViewState in SQL Server:
MSDN - Übersicht über PageStatePersister
ASP Alliance - Einfache Methode zum Speichern von ViewState in SQL Server
Code Project - ViewState-Anbietermodell

Nachdem urlDecode den Text verarbeitet hat, werden alle '+' Zeichen durch '' ersetzt ... daher der Fehler. Sie sollten diese Anweisung einfach aufrufen, um Base 64 wieder kompatibel zu machen:

        sEncryptedString = sEncryptedString.Replace(' ', '+');

Ich vermute, dass etwas entweder zu oft codiert oder decodiert - oder dass Sie Text mit mehreren Zeilen haben.

Base64-Zeichenfolgen müssen ein Vielfaches von 4 Zeichen lang sein - alle 4 Zeichen stehen für 3 Byte Eingabedaten. Irgendwie sind die von ASP.NET zurückgegebenen Ansichtsstatusdaten beschädigt - die Länge ist kein Vielfaches von 4.

Protokollieren Sie den Benutzeragenten, wenn dies auftritt? Ich frage mich, ob es irgendwo ein schlecht benommener Browser ist ... eine andere Möglichkeit ist, dass es einen Proxy gibt, der ungezogene Dinge tut. Versuchen Sie ebenfalls, die Inhaltslänge der Anforderung zu protokollieren, damit Sie sehen können, ob dies nur bei großen Anforderungen der Fall ist.

Versuche dies:

public string EncodeBase64(string data)
{
    string s = data.Trim().Replace(" ", "+");
    if (s.Length % 4 > 0)
        s = s.PadRight(s.Length + 4 - s.Length % 4, '=');
    return Encoding.UTF8.GetString(Convert.FromBase64String(s));
}

int len = qs.Length % 4;
            if (len > 0) qs = qs.PadRight(qs.Length + (4 - len), '=');

Wo qsist eine Base64-codierte Zeichenfolge?

Wie bereits erwähnt, kann dies verursacht werden, wenn einige Firewalls und Proxys den Zugriff auf Seiten mit einer großen Menge an ViewState-Daten verhindern.

ASP.NET 2.0 führte den ViewState Chunking-Mechanismus ein der den ViewState in verwaltbare , sodass der ViewState problemlos den Proxy / die Firewall passieren kann.

Um diese Funktion zu aktivieren, fügen Sie einfach die folgende Zeile zu Ihrer web.config-Datei hinzu.

<pages maxPageStateFieldLength="4000">

Dies sollte nicht als Alternative zur Reduzierung Ihrer ViewState-Größe verwendet werden, kann jedoch ein wirksamer Rückschlag gegen den Fehler "Ungültige Länge für ein Base-64-Zeichenarray" sein, der sich aus aggressiven Proxys und dergleichen ergibt.

Dies ist leider keine Antwort. Nachdem ich einige Zeit auf den zeitweiligen Fehler gestoßen bin und mich schließlich genug geärgert habe, um zu versuchen, ihn zu beheben, muss ich noch eine Lösung finden. Ich habe jedoch ein Rezept für die Reproduktion meines Problems festgelegt, das anderen helfen könnte.

In meinem Fall handelt es sich NUR um ein Localhost-Problem auf meinem Entwicklungscomputer, auf dem sich auch die Datenbank der App befindet. Es ist eine .NET 2.0-App, die ich mit VS2005 bearbeite. Auf dem Win7 64-Bit-Computer sind auch VS2008 und .NET 3.5 installiert.

Folgendes erzeugt den Fehler in verschiedenen Formen:

1. Laden Sie eine neue Kopie des Formulars.
2. Geben Sie einige Daten und / oder Postbacks mit einem der Steuerelemente des Formulars ein. Wiederholen Sie alles, was Sie möchten, solange keine nennenswerte Verzögerung auftritt und keine Fehler auftreten.
3. Warten Sie eine Weile (vielleicht 1 oder 2 Minuten, nicht mehr als 5) und versuchen Sie es mit einem anderen Postback.

Ein oder zwei Minuten Verzögerung "Warten auf localhost" und dann "Verbindung wurde zurückgesetzt" vom Browser und global.asaxdie Anwendungsfehler-Trap-Protokolle der Anwendung:

Application_Error event: Invalid length for a Base-64 char array.
Stack Trace:
     at System.Convert.FromBase64String(String s)
     at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
     at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
     at System.Web.UI.HiddenFieldPageStatePersister.Load()

In diesem Fall ist es nicht die GRÖSSE des Ansichtszustands, sondern etwas, das mit dem Zwischenspeichern von Seiten und / oder Ansichtszuständen zu tun hat, das mich zu beißen scheint. Das Einstellen von <pages>Parametern enableEventValidation="false"und viewStateEncryption="Never"in Web.confighat das Verhalten nicht geändert. Auch das Setzen maxPageStateFieldLengthauf etwas Bescheidenes.

Schauen Sie sich Ihre HttpHandlers an. Ich habe in den letzten Monaten einige seltsame und völlig zufällige Fehler bemerkt, nachdem ich ein Komprimierungswerkzeug (RadCompression von Telerik) implementiert habe. Ich bemerkte Fehler wie:

• System.Web.HttpException: Daten können nicht überprüft werden.

• System.Web.HttpException: Der Client wurde getrennt .---> System.Web.UI.ViewStateException: Ungültiger Ansichtsstatus.

und

• System.FormatException: Ungültige Länge für ein Base-64-Zeichenarray.

• System.Web.HttpException: Der Client wurde getrennt. ---> System.Web.UI.ViewStateException: Ungültiger Ansichtsstatus.

Ich habe darüber in meinem Blog geschrieben.

Dies liegt an einem riesigen Ansichtsstatus. In meinem Fall hatte ich Glück, da ich den Ansichtsstatus nicht verwendet habe. Ich habe gerade hinzugefügtenableviewstate="false" das Formular-Tag und der Ansichtsstatus stieg von 35.000 auf 100 Zeichen

Beim ersten Testen auf Membership.ValidateUser mit einem SqlMembershipProvider verwende ich einen Hash-Algorithmus (SHA1) in Kombination mit einem Salt. Wenn ich die Salt-Länge auf eine Länge geändert habe, die nicht durch vier teilbar ist, habe ich diesen Fehler erhalten.

Ich habe keine der oben genannten Korrekturen versucht, aber wenn das Salz geändert wird, kann dies jemandem helfen, dies als Ursache für diesen bestimmten Fehler zu identifizieren.

Wie Jon Skeet sagte, muss die Zeichenfolge ein Vielfaches von 4 Bytes sein. Aber ich bekam immer noch den Fehler.

Zumindest wurde es im Debug-Modus entfernt. Setzen Sie einen Haltepunkt Convert.FromBase64String()und gehen Sie den Code durch. Wie durch ein Wunder ist der Fehler für mich verschwunden :) Er hängt wahrscheinlich mit den Ansichtszuständen und ähnlichen anderen Problemen zusammen, die andere gemeldet haben.

Zusätzlich zu der Lösung von @ jalchr , die mir geholfen hat, stellte ich fest, dass Sie beim Aufrufen ATL::Base64Encodevon einer C ++ - Anwendung zum Codieren des Inhalts, den Sie an einen ASP.NET-Webservice übergeben, noch etwas anderes benötigen. Zusätzlich zu

sEncryptedString = sEncryptedString.Replace(' ', '+'); 

Bei der Lösung von @ jalchr müssen Sie außerdem sicherstellen, dass Sie dasATL_BASE64_FLAG_NOPAD Flag nicht verwenden für ATL::Base64Encode:

 BOOL bEncoded = Base64Encode(lpBuffer,
                    nBufferSizeInBytes,
                    strBase64Encoded.GetBufferSetLength(base64Length),
                    &base64Length,ATL_BASE64_FLAG_NOCRLF/*|ATL_BASE64_FLAG_NOPAD*/);