Derzeit sendet ein Teil meiner Anwendung E-Mails an Benutzer, die sie an Ereignisse oder Aufgaben erinnern. Wenn Sie im E-Mail-Client auf einen MarkComplete -Link klicken, wird eine HTTP-Get-Anforderung an meinen ActionHandler.ashx (ein HTTPHandler) gesendet, wo die QueryString-Parameter Eingaben für die Aktualisierung von sind das Ereignis / die Aufgabe. Neue E-Mails werden dann an den Client zurückgesendet, der die Beendigung signalisiert. Das funktioniert.
Ein unerwünschter Nebeneffekt dieses HTTP GET auf den Handler ist das Starten des Browsers (d. h. zu diesem Zeitpunkt ist das Öffnen des Browsers unnötig und lästig).
Prämisse : Wenn ich mich mit ASP.Net Web Api beschäftige, denke ich, dass ich die kleine Menge Code in meinem HTTPHandler in eine PUT-Methode in einem Web-API-Controller umwandeln kann . Mein Verständnis ist, dass dieser Controller nach der oben beschriebenen erforderlichen Verarbeitung mit void return (HTTP-Statuscode 204) antworten könnte.
Frage : Kann der obige Ansatz in einer neu geschriebenen PUT-Methode in einem Web-API-Controller 204 zurückgeben und verhindert dies, dass der Browser vollständig gestartet wird? Ich möchte, dass der Endanwender in seiner ersten E-Mail auf den Link klickt und nur die neu erstellte E-Mail-Nachricht "Completion" (überhaupt kein Browser) erhält.
EDITs zur Klärung 22. Mai 2016:
Kurze Antwort: Nein .
Wenn Sie eine Benutzerinteraktion benötigen, gibt es keine Möglichkeit, eine HTTP-Anfrage von einem E-Mail-Client auszuführen, ohne den Browser zu öffnen.
Die meisten E-Mail-Clients (einschließlich Webmails) erlauben dies nicht Führen Sie JavaScript Code aus und Sie haben somit keine Möglichkeit etwas im Hintergrund auszuführen.
Dies bedeutet, dass Sie zwei Optionen haben:
GET -Anforderung an Ihren Webserver führt (was Sie bereits getan haben). Dies führt natürlich dazu, dass der Browser diese Seite öffnet. POST enabled Endpunkt innerhalb Ihres Webservers abzielt. Dies führt auch dazu, dass der Webbrowser geöffnet wird () und in einigen Szenarien möglicherweise eine Warnmeldung angezeigt wird ), aber Sie können besser handhaben, welche Art von Daten zu senden. ABER scheint dieser Ansatz eng an das spezifische Client-Verhalten gebunden zu sein (z. B. macht Thunderbird jede Formularübertragung in eine GET -Anforderung), also glaube ich nicht, dass es machbar ist. Abgesehen von diesen beiden Möglichkeiten, glaube ich, haben Sie keine Möglichkeiten. Der Grund dafür ist rein sicherheitsbezogen: Es wäre sehr unsicher, wenn Sie JavaScript-Code in einer E-Mail-Nachricht ausführen könnten.
Was Sie tun können , besteht darin, die Antwort Ihres Endpunkts in ein 204 umzuwandeln (wie Sie es vorgeschlagen haben). Bitte beachten Sie, dass dies auch dazu führt, dass Ihr Browser geöffnet wird, aber es wird fast sofort die Registerkarte schließen, die mit einer 204 beantwortet hat (das genaue Verhalten hängt von der E-Mail-Client- und Webbrowser-Kombination ab).
Ich denke, das kann leicht gemacht werden, selbst wenn Sie Ihre Codebasis nicht ändern und weiterhin ActionHandler.ashx verwenden, aber wenn Sie möchten, können Sie das natürlich einfach in der ASP.NET-Web-API tun. returning void von ActionMethod .
PUT : In HTML-Formularen sind nur GET und POST erlaubte Methoden , während jede Art von <a href="... ">...</a> -Tag immer eine GET -Anfrage erzeugt. Das bedeutet, dass Sie die PUT -Methode nicht innerhalb einer E-Mail-Nachricht ausführen können (egal in welcher Umgebung die E-Mail gelesen wird).
Wenn Sie eine Aktion in einer E-Mail ausführen möchten, müssen Sie einen Webbrowser öffnen. Andernfalls wäre dies ein großes Sicherheitsrisiko auf der Seite des Kunden. Wenn dies eine Option wäre, würde dies die Tür für Spammer öffnen, und Hacks, um eine E-Mail zu erhalten, wo Sie irgendwo klicken und automatisch eine Anwendung herunterladen (BIG SECURITY CONCERN).
Es gibt andere Möglichkeiten, diese Art von Anwendung zu handhaben. Wir verwenden sowohl Textnachrichten als auch PDF-Formulare, die auf eine Anwendungsanfrage antworten können. SharePoint tut dies, solange der Client Teil Ihrer Infrastruktur ist. Google tut dies jetzt mit Markup für eine Art RSVP und hebt E-Mails hervor, funktioniert aber nur bei Kunden, die sich die Markup-Sprache anschauen und mit ihren Apps googlen. Die meisten E-Mail-Clients ignorieren Markup und Skripte in einer E-Mail. Ich kenne wirklich niemanden, der im heutigen Alter kein Handy hat, selbst meine Großmutter im Alter von 75 Jahren hat ein Handy. Ich würde empfehlen, twilio und SignalR zu verwenden . Eine andere Möglichkeit besteht darin, einige E-Mail-Konten einzurichten, die von Ihrer Anwendung überwacht werden, z. B. [email protected] und [email protected]. Wenn der Client nun akzeptiert, sendet er eine Antwort an diese E-Mail und Ihre Anwendung kann die E-Mail-Adresse in der Kopfzeile betrachten, um diesen Account zu markieren. Dadurch erhalten Sie auch Datensätze, auf die Sie zurückblicken können, wenn ein Problem mit dem Client aufgetreten ist.
>Was das Öffnen des Browsers anbelangt, glaube ich nicht, dass dies eine schlechte Sache ist. Dadurch werden sie an Ihre Anwendung zurückgeschickt und gezwungen, neue Informationen, Ereignisse oder Aufgaben zu sehen, die Sie gepostet haben (Marketing).
Erstens, um eine HTTP-Anfrage zu senden, unabhängig von dem verwendeten Verb (GET, POST, PUT, DELETE, HEAD usw.) benötigen Sie dafür ein externes Programm (Browser, Shell, etc.) E-Mail-Clients werden dies nicht tun.
Wenn Sie die Verwendung eines Webbrowsers vermeiden möchten, können Sie sich andere Möglichkeiten überlegen, z. B. die erste E-Mail, die Sie an den Benutzer gesendet haben, mit einem bestimmten Betreff wie "Terminbestätigung" konfigurieren und den Benutzer auffordern, dies zu beantworten Wenn Sie eine E-Mail senden, erhalten Sie eine E-Mail mit dem ursprünglichen Betreff, den Sie an den Benutzer gesendet haben. Anschließend können Sie Ihre Anwendung so konfigurieren, dass diese eingehenden E-Mails erwartet werden. Sie haben sogar so viele Informationen des Benutzers, wie Sie in der ersten E-Mail angegeben haben, dies kann verwendet werden, um die zweite E-Mail zu konfigurieren.
Tags und Links asp.net-web-api http asp.net-mvc-4 vb.net email-client