Ich habe eine App mit Silverlight4, RIA Services erstellt und verwende ASP.NET-Mitgliedschaft für die Authentifizierung / Autorisierung.
Meine web.config hat folgendes:
%Vor%Ich habe eine Reihe verschiedener Strategien gelesen, wie mit dem Timeout von Authentifizierungs- / Sitzungszeiten auf der Client-Seite umgegangen werden kann. Das heißt: Wenn der Client für x Minuten inaktiv ist (hier 20) und dann etwas mit der Benutzeroberfläche ausführt, die einen RIA / WCF-Aufruf auslöst, möchte ich dieses Ereignis abfangen und entsprechend behandeln (z. B. zurück in den Anmeldebildschirm) - Kurz gesagt: Ich brauche eine Möglichkeit, mich von einer seriösen DomainException auf der Serverseite gegenüber einem Auth-Fehler zu unterscheiden, weil die Sitzung abgelaufen ist.
AFAIK: Es gibt keine typisierte Ausnahme oder Eigenschaft, die dies feststellen kann. Der einzige Weg, wie ich das feststellen konnte - was wie ein Hack aussieht: ist es, die Nachrichtenfolge des Error zu überprüfen und nach etwas wie "Access denied" oder "denied" zu suchen. Zum Beispiel: etwas in der Art:
%Vor%Also, das ist, was ich gerade mache, und es funktioniert, wenn ich entweder mit dem eingebauten Server von VS2010 laufe und debugge, oder wenn ich in localhost IIS laufe. Wenn ich das Timeout auf 1 Minute setze, logge mich ein, warte länger als eine Minute und triggeriere einen weiteren Anruf, brich ich den Breakpoint auf der Exception und gebe den obigen if code block ein und alles ist gut.
Dann stelle ich die App auf einem entfernten IIS7-Server bereit und versuche den gleichen Test und es funktioniert nicht. Also habe ich die Protokollverfolgung hinzugefügt, und hier ist das Ereignis, bei dem die Ausnahme passiert ist:
%Vor%Das Problem ist, dass ich nicht die Zeichenfolge in der Fehlermeldung, die "verweigert" oder "Zugriff verweigert" angibt - und ich bin mir nicht sicher, warum diese Lösung in Localhost IIS oder VS2010-Host funktioniert, aber nicht in einem Remote IIS7-Server. Gibt es eine obskure Konfigurationseinstellung, die mir hier fehlt? Gibt es einen besseren Weg, dies generell zu tun?
Sie haben das wahrscheinlich schon verstanden, aber dieser Artikel beschreibt die Verwendung der DomainOperationException und die Überprüfung der Fehlercodes.
%Vor%Für einen bequemen Zugang (und für den Fall, dass wir den Zugang zum Blog verlieren), hier ist der Blog-Artikel von Josh Eastburn:
%Vor%Eine Frage, die häufig von Entwicklern kommt, die mit Silverlight und WCF RIA Services arbeiten: Warum gibt meine Silverlight-Anwendung eine Ausnahme aus, wenn sie für eine gewisse Zeit inaktiv war? Wie Sie vielleicht erwarten können, liegt dies an der Zeitüberschreitung der authentifizierten Sitzung. Aber es ist nicht ganz so einfach. Da Silverlight eine Client / Server-Architektur verwendet, kann der Client für eine unbestimmte Zeit unabhängig vom Server arbeiten. Nur wenn der Silverlight-Client den Server aufruft, wird das serverseitige Timeout erreicht. Es gibt einige Optionen, um das Client-Server-Timeout-Problem zu beheben (und Sie können vielleicht noch ein paar mehr): Wenn Sie sich nicht mit den Sicherheitsauswirkungen des Entfernens eines Sitzungszeitlimits beschäftigen, können Sie das Zeitlimit erhöhen Legen Sie in web.config fest oder erstellen Sie einen DispatcherTimer im Silverlight-Client, der eine einfache Methode auf dem Server aufruft, die als "Keep Alive" fungiert. Fügen Sie dem Silverlight-Client einen DispatcherTimer hinzu, der mit dem serverseitigen Zeitlimit synchronisiert bleibt, und warnen Sie den Benutzer, dass die Sitzung vor Ablauf der Zeit aktiv bleibt, oder lassen Sie sie erneut authentifizieren, wenn sie bereits abgelaufen ist. Dies erfordert jedoch zusätzlichen Aufwand, um die Zeitgeber synchronisiert zu halten, wenn neue Serveranforderungen gestellt werden. Erlauben Sie dem Server, das Zeitlimit wie gewohnt zu behandeln und das Zeitlimit auf dem Silverlight-Client ordnungsgemäß zu behandeln. Dies bedeutet, dass die Zeitüberschreitung durch die Serveranrufaktivität bestimmt wird, NOT-Aktivität beschränkt den Silverlight-Client (d. H. Zugriff auf clientseitige Daten in dem Kontext). Von diesen drei Optionen finde ich, dass die dritte die beste Balance aus Sicherheit und Benutzerfreundlichkeit ist und gleichzeitig der Anwendung keine unnötige Komplexität hinzufügt. Um diese serverseitigen Timeouts global zu behandeln, können Sie die folgende Logik entweder in der Application_UnhandledException-Methode in App.xaml.cs oder in Ihrem globalen ViewModel-Ladekonstrukt hinzufügen, wenn Sie eines haben:
%Vor%Die folgenden Konstanten sind in der ErrorCodes-Klasse definiert:
%Vor%Wenn die serverseitige Sitzung abläuft, geben alle nachfolgenden Aufrufe eine DomainOperationException zurück. Durch Überprüfen des zurückgegebenen ErrorCodes können Sie feststellen, ob es sich um einen Authentifizierungsfehler handelt, und diesen entsprechend behandeln. In meinem Beispiel rufe ich WebContext.Current.Authentication.LoadUser () auf, das versucht, den Benutzer nach Möglichkeit erneut zu authentifizieren. Selbst wenn der Benutzer nicht automatisch erneut authentifiziert werden kann, ruft er die Methode Application_UserLoaded auf. Dort kann ich WebContext.Current.User.IsAuthenticated überprüfen, um zu bestimmen, ob mit dem vorherigen Vorgang fortgefahren werden soll oder ob ich zurück zur Homepage umleiten und erneut zur Anmeldung auffordern muss. Hier ist ein Beispiel für einen Code im Appliation_UserLoaded-Callback, der ein Anmeldedialogfeld anzeigt, wenn der Benutzer nicht authentifiziert ist:
%Vor%Um Ihren Code zu testen, können Sie den Zeitüberschreitungswert in web.config auf a einstellen kleiner Wert, so dass Timeouts schnell auftreten:
Wenn Sie den gesamten Code in einer funktionierenden Lösung sehen möchten, lesen Sie unsere Silverlight RIA-Vorlage auf CodePlex .
Tags und Links silverlight silverlight-4.0 asp.net-membership wcf-ria-services