So verwenden Sie das ASP.NET Framework SDK für Azure Mobile Apps
Anmerkung
Dieses Produkt wird eingestellt. Eine Ersetzung für Projekte mit .NET 8 oder höher finden Sie in der Community Toolkit Datasync-Bibliothek.
In diesem Thema erfahren Sie, wie Sie das .NET-Back-End-Server-SDK in wichtigen Azure App Service Mobile Apps-Szenarien verwenden. Das Azure Mobile Apps SDK hilft Ihnen bei der Arbeit mit mobilen Clients aus Ihrer ASP.NET-Anwendung.
Warnung
In diesem Artikel werden Informationen für die v4.2.0-Bibliotheksversion behandelt, die von der v5.0.0-Bibliothek ersetzt wird. Die aktuellsten Informationen finden Sie im Artikel zur neuesten Version
Erstellen eines Azure Mobile Apps ASP.NET Framework-Back-End
Sie können eine ASP.NET Framework-App mit Visual Studio 2019 erstellen.
- Wählen Sie die Vorlage ASP.NET Webanwendung (.NET Framework) aus. Wenn Sie Probleme beim Auffinden dieser Vorlage haben, wählen Sie C#-, Alle Plattformenund Web-aus.
- Nachdem Sie einen Namen und speicherort für die Anwendung ausgewählt haben, wählen Sie die Web-API Projektvorlage aus. Die richtige Sammlung von Basisdiensten für Ihre Anwendung wird installiert.
Herunterladen und Initialisieren des SDK
Das SDK ist auf NuGet.orgverfügbar und stellt die Basisfunktionalität bereit, die für die ersten Schritte mit Azure Mobile Apps erforderlich ist. So installieren Sie das Paket:
- Klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie dann NuGet-Pakete verwalten...aus.
- Geben Sie auf der Registerkarte Durchsuchen im Suchfeld
Microsoft.Azure.Mobile.Server
ein, und drücken Sie dann die EINGABETASTE. - Wählen Sie das
Microsoft.Azure.Mobile.Server.Quickstart
Paket aus. - Klicken Sie auf installieren.
- Folgen Sie den Anweisungen, um die Installation abzuschließen.
Wiederholen Sie den Vorgang, um Microsoft.Owin.Host.SystemWeb
zu installieren.
Anmerkung
Aktualisieren Sie nicht die Pakete, die als Abhängigkeiten verwendet werden, z. B. Newtonsoft.JSON
oder System.IdentityModel.Jwt
. Die APIs dieser Pakete haben sich in vielen Fällen geändert und sind jetzt mit Azure Mobile Apps für ASP.NET Framework nicht kompatibel.
Initialisieren des Serverprojekts
Ein Azure Mobile Apps-Serverprojekt wird ähnlich wie andere ASP.NET Framework-Projekte initialisiert. durch Einschließen einer OWIN-Startklasse. So fügen Sie eine OWIN-Startklasse hinzu:
Klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie dann Hinzufügen>Neues Element
Wählen Sie
Web Allgemeine aus, und wählen Sie dann dieVorlage der OWIN-Startklasse aus.Geben Sie den Namen
Startup.cs
als Startnamen ein.Der Inhalt der datei
Startup.cs
sollte dem folgenden Code ähneln:using Microsoft.Azure.Mobile.Server.Config; using Microsoft.Owin; using Owin; using System.Web.Http; [assembly: OwinStartup(typeof(WebApplication1.Startup))] namespace WebApplication1 { public class Startup { public void Configuration(IAppBuilder app) { HttpConfiguration config = new HttpConfiguration(); new MobileAppConfiguration() // no added features .ApplyTo(config); app.UseWebApi(config); } } }
Je nach Projekt unterscheiden sich die
OwinStartup
, der Namespace und der Klassenname. Insbesondere sollten Sie den Inhalt derConfiguration()
-Methode ersetzen und dieusing
Direktiven entsprechend anpassen.
Um einzelne Features zu aktivieren, müssen Sie Erweiterungsmethoden für das MobileAppConfiguration--Objekt aufrufen, bevor Sie ApplyToaufrufen. Der folgende Code fügt z. B. alle API-Controller, die das Attribut [MobileAppController]
haben, während der Initialisierung die Standardrouten hinzu:
new MobileAppConfiguration()
.MapApiControllers()
.ApplyTo(config);
Das folgende Setup wird als "normale" Verwendung betrachtet, mit der Sowohl Tabellen- als auch API-Controller mit Entity Framework auf einen SQL-Dienst zugreifen können.
new MobileAppConfiguration()
.AddMobileAppHomeController()
.MapApiControllers()
.AddTables(
new MobileAppTableConfiguration()
.MapTableControllers()
.AddEntityFramework()
)
.MapLegacyCrossDomainController()
.ApplyTo(config);
Die verwendeten Erweiterungsmethoden sind:
-
AddMobileAppHomeController()
stellt die Standardmäßige Startseite von Azure Mobile Apps bereit. -
MapApiControllers()
stellt benutzerdefinierte API-Funktionen für WebAPI-Controller bereit, die mit dem[MobileAppController]
-Attribut versehen sind. -
AddTables()
stellt eine Zuordnung der/tables
Endpunkte zu Tabellencontrollern bereit. -
AddTablesWithEntityFramework()
ist eine kurze Hand für die Zuordnung der/tables
Endpunkte mithilfe von Entity Framework-basierten Controllern. -
MapLegacyCrossDomainController()
stellt standardmäßige CORS-Header für die lokale Entwicklung bereit.
SDK-Erweiterungen
Die folgenden NuGet-basierten Erweiterungspakete bieten verschiedene mobile Features, die von Ihrer Anwendung verwendet werden können. Sie aktivieren Erweiterungen während der Initialisierung mithilfe des MobileAppConfiguration-Objekts.
- Microsoft.Azure.Mobile.Server.Quickstart- Unterstützt das grundlegende Setup mobiler Apps. Hinzugefügt zur Konfiguration durch Aufrufen der UseDefaultConfiguration Erweiterungsmethode während der Initialisierung. Diese Erweiterung umfasst die folgenden Erweiterungen: Benachrichtigungen, Authentifizierung, Entität, Tabellen, domänenübergreifende und Home-Pakete.
- Microsoft.Azure.Mobile.Server.Home Implementiert die Standard-diese mobile App auf der Seite ausgeführt wird, für den Stamm der Website. Fügen Sie der Konfiguration hinzu, indem Sie die AddMobileAppHomeController Erweiterungsmethode aufrufen.
- Microsoft.Azure.Mobile.Server.Tables enthält Klassen für das Arbeiten mit Daten und das Einrichten der Datenpipeline. Fügen Sie der Konfiguration hinzu, indem Sie die AddTables Erweiterungsmethode aufrufen.
- Microsoft.Azure.Mobile.Server.Entity Ermöglicht dem Entity Framework den Zugriff auf Daten in der SQL-Datenbank. Fügen Sie der Konfiguration hinzu, indem Sie die AddTablesWithEntityFramework Erweiterungsmethode aufrufen.
- Microsoft.Azure.Mobile.Server.Authentication Aktiviert die Authentifizierung und richtet die OWIN-Middleware ein, die zum Überprüfen von Token verwendet wird. Fügen Sie der Konfiguration hinzu, indem Sie die AddAppServiceAuthentication und IAppBuilder-aufrufen.UseAppServiceAuthentication Erweiterungsmethoden.
- Microsoft.Azure.Mobile.Server.Notifications Aktiviert Pushbenachrichtigungen und definiert einen Endpunkt für die Pushregistrierung. Fügen Sie der Konfiguration hinzu, indem Sie die AddPushNotifications Erweiterungsmethode aufrufen.
- Microsoft.Azure.Mobile.Server.CrossDomain Erstellt einen Controller, der Daten für ältere Webbrowser aus Ihrer mobilen App liefert. Fügen Sie der Konfiguration hinzu, indem Sie die MapLegacyCrossDomainController Erweiterungsmethode aufrufen.
-
Microsoft.Azure.Mobile.Server.Login Stellt die
AppServiceLoginHandler.CreateToken()
-Methode bereit, die bei benutzerdefinierten Authentifizierungsszenarien verwendet wird.
Veröffentlichen des Serverprojekts
In diesem Abschnitt erfahren Sie, wie Sie Ihr .NET-Back-End-Projekt aus Visual Studio veröffentlichen. Es gibt andere Methoden, mit denen Sie Ihre Anwendung veröffentlichen können. Weitere Informationen finden Sie in der Azure App Service-Dokumentation.
- Erstellen Sie in Visual Studio das Projekt neu, um NuGet-Pakete wiederherzustellen.
- Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, und klicken Sie auf veröffentlichen.
- Wenn Sie dieses Projekt noch nicht veröffentlicht haben, konfigurieren Sie die Veröffentlichung.
- Wählen Sie Azure für das Ziel aus.
- Wählen Sie Azure App Service (Windows) für das jeweilige Ziel aus.
- Wählen Sie die App-Dienstinstanz aus, für die Sie bereitstellen möchten. Wenn Sie keins haben, verwenden Sie die +, um eins zu erstellen.
- Klicken Sie auf Fertig stellen.
- Wenn Sie zuvor keine SQL-Datenbank verknüpft haben, klicken Sie auf Konfigurieren von neben der SQL-Datenbank.
- Wählen Sie Azure SQL-Datenbank
- Wählen Sie Ihre Datenbank aus. Wenn Sie nicht über eine andere verfügen oder eine andere verwenden möchten, klicken Sie auf die +, um eine neue Datenbank und einen neuen Server zu erstellen.
- Geben Sie
MS_TableConnectionString
als Namen der Datenbankverbindungszeichenfolge ein. Geben Sie den Benutzernamen und das Kennwort in den angegebenen Feldern ein. - Klicken Sie auf Fertig stellen
- Klicken Sie auf veröffentlichen
Es dauert einige Zeit, um in Azure zu veröffentlichen. Weitere Informationen finden Sie unter der Visual Studio-Dokumentation.
Definieren eines Tabellencontrollers
Definieren Sie einen Tabellencontroller, um eine SQL-Tabelle für mobile Clients verfügbar zu machen. Das Konfigurieren eines Tabellencontrollers erfordert drei Schritte:
- Erstellen Sie eine DTO-Klasse (Data Transfer Object).
- Konfigurieren Sie einen Tabellenverweis in der Mobile DbContext-Klasse.
- Erstellen Sie einen Tabellencontroller.
Ein Data Transfer Object (DTO) ist ein einfaches C#-Objekt, das von EntityData
erbt. Zum Beispiel:
public class TodoItem : EntityData
{
public string Text { get; set; }
public bool Complete {get; set;}
}
Das DTO wird verwendet, um die Tabelle in der SQL-Datenbank zu definieren. Um den Datenbankeintrag zu erstellen, fügen Sie der verwendeten DbContext
eine DbSet<>
-Eigenschaft hinzu:
public class MobileServiceContext : DbContext
{
private const string connectionStringName = "Name=MS_TableConnectionString";
public MobileServiceContext() : base(connectionStringName)
{
}
public DbSet<TodoItem> TodoItems { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Add(
new AttributeToColumnAnnotationConvention<TableColumnAttribute, string>(
"ServiceColumnTable", (property, attributes) => attributes.Single().ColumnType.ToString()));
}
}
Erstellen Sie schließlich einen neuen Controller:
Klicken Sie mit der rechten Maustaste auf den Ordner
Controllers
.Wählen Sie Web-API>Web-API 2-Controller aus – leer
Geben Sie einen Namen für den Controller ein.
Ersetzen Sie den Inhalt des neuen Controllers durch den folgenden Code:
public class TodoItemController : TableController<TodoItem> { protected override void Initialize(HttpControllerContext controllerContext) { base.Initialize(controllerContext); ZUMOAPPNAMEContext context = new ZUMOAPPNAMEContext(); DomainManager = new EntityDomainManager<TodoItem>(context, Request); } // GET tables/TodoItem public IQueryable<TodoItem> GetAllTodoItems() { return Query(); } // GET tables/TodoItem/48D68C86-6EA6-4C25-AA33-223FC9A27959 public SingleResult<TodoItem> GetTodoItem(string id) { return Lookup(id); } // PATCH tables/TodoItem/48D68C86-6EA6-4C25-AA33-223FC9A27959 public Task<TodoItem> PatchTodoItem(string id, Delta<TodoItem> patch) { return UpdateAsync(id, patch); } // POST tables/TodoItem public async Task<IHttpActionResult> PostTodoItem(TodoItem item) { TodoItem current = await InsertAsync(item); return CreatedAtRoute("Tables", new { id = current.Id }, current); } // DELETE tables/TodoItem/48D68C86-6EA6-4C25-AA33-223FC9A27959 public Task DeleteTodoItem(string id) { return DeleteAsync(id); } }
Anpassen der Tabellen paging-Größe
Standardmäßig gibt Azure Mobile Apps 50 Datensätze pro Anforderung zurück. Durch Paging wird sichergestellt, dass der Client seinen UI-Thread oder den Server nicht zu lange bindet und so eine gute Benutzererfahrung gewährleistet. Um die Tabellenseitengröße zu ändern, vergrößern Sie die serverseitige "zulässige Abfragegröße" und die clientseitige Seitengröße Die serverseitige "zulässige Abfragegröße" wird mithilfe des attributs EnableQuery
angepasst:
[EnableQuery(PageSize = 500)]
Stellen Sie sicher, dass die PageSize-Größe identisch oder größer ist als die vom Client angeforderte Größe. Ausführliche Informationen zum Ändern der Clientseitengröße finden Sie in der spezifischen Client-HOWTO-Dokumentation.
Definieren eines benutzerdefinierten API-Controllers
Der benutzerdefinierte API-Controller bietet die grundlegendsten Funktionen für Ihr Mobile App-Back-End, indem ein Endpunkt verfügbar ist. Sie können einen mobilen API-Controller mithilfe des [MobileAppController]-Attributs registrieren. Das attribut MobileAppController
registriert die Route, richtet den JSON-Serializer für mobile Apps ein und aktiviert die Clientversionsprüfung.
Die Inhalte des benutzerdefinierten API-Controllers sind:
[MobileAppController]
public class CustomAPIController : ApiController
{
// Content here
}
Nach der Konfiguration mit dem MobileAppController
-Attribut können Sie die benutzerdefinierte API auf die gleiche Weise wie jede andere Web-API definieren.
Arbeiten mit Authentifizierung
Azure Mobile Apps verwendet die App Service-Authentifizierung/Autorisierung, um Ihr mobiles Back-End zu sichern. In diesem Abschnitt wird gezeigt, wie Sie die folgenden authentifizierungsbezogenen Aufgaben in Ihrem .NET-Back-End-Serverprojekt ausführen:
- Hinzufügen der Authentifizierung zu einem Serverprojekt
- Verwenden der benutzerdefinierten Authentifizierung für Ihre Anwendung
- Abrufen authentifizierter Benutzerinformationen
- Einschränken des Datenzugriffs für autorisierte Benutzer
Hinzufügen der Authentifizierung zu einem Serverprojekt
Sie können Ihrem Serverprojekt die Authentifizierung hinzufügen, indem Sie die MobileAppConfiguration-Objekt erweitern und OWIN-Middleware konfigurieren.
Installieren Sie in Visual Studio das Microsoft.Azure.Mobile.Server.Authentication-Paket.
Fügen Sie in der projektdatei
Startup.cs
die folgende Codezeile am Anfang der Configuration-Methode hinzu:app.UseAppServiceAuthentication(config);
Diese OWIN-Middlewarekomponente überprüft Token, die vom zugeordneten App Service-Gateway ausgestellt wurden.
Fügen Sie das attribut
[Authorize]
jedem Controller oder einer Methode hinzu, die eine Authentifizierung erfordert.
Verwenden der benutzerdefinierten Authentifizierung für Ihre Anwendung
Wichtig
Um die benutzerdefinierte Authentifizierung zu aktivieren, müssen Sie zuerst die App-Dienstauthentifizierung aktivieren, ohne einen Anbieter für Ihren App-Dienst im Azure-Portal auszuwählen. Dadurch wird die WEBSITE_AUTH_SIGNING_KEY
Umgebungsvariable aktiviert, wenn sie gehostet wird.
Wenn Sie keinen der App Service-Authentifizierungs-/Autorisierungsanbieter verwenden möchten, können Sie Ihr eigenes Anmeldesystem implementieren. Installieren Sie das Microsoft.Azure.Mobile.Server.Login Paket, um die Generierung von Authentifizierungstoken zu unterstützen. Geben Sie Ihren eigenen Code für die Überprüfung von Benutzeranmeldeinformationen an. Sie können beispielsweise auf gesalzene und hashierte Kennwörter in einer Datenbank überprüfen. Im folgenden Beispiel ist die isValidAssertion()
-Methode (an anderer Stelle definiert) für diese Prüfungen verantwortlich.
Die benutzerdefinierte Authentifizierung wird verfügbar gemacht, indem ein ApiController erstellt und aktionen register
und login
verfügbar gemacht werden. Der Client sollte eine benutzerdefinierte Benutzeroberfläche verwenden, um die Informationen vom Benutzer zu sammeln. Die Informationen werden dann mit einem standardmäßigen HTTP POST-Aufruf an die API übermittelt. Sobald der Server die Assertion überprüft, wird ein Token mithilfe der AppServiceLoginHandler.CreateToken()
-Methode ausgegeben. Der ApiController-sollte das attribut [MobileAppController]
nicht verwenden.
Beispiel login
Aktion:
public IHttpActionResult Post([FromBody] JObject assertion)
{
if (isValidAssertion(assertion)) // user-defined function, checks against a database
{
JwtSecurityToken token = AppServiceLoginHandler.CreateToken(new Claim[] { new Claim(JwtRegisteredClaimNames.Sub, assertion["username"]) },
mySigningKey,
myAppURL,
myAppURL,
TimeSpan.FromHours(24) );
return Ok(new LoginResult()
{
AuthenticationToken = token.RawData,
User = new LoginResultUser() { UserId = userName.ToString() }
});
}
else // user assertion was not valid
{
return this.Request.CreateUnauthorizedResponse();
}
}
Im vorherigen Beispiel sind LoginResult
und LoginResultUser
serialisierbare Objekte, die erforderliche Eigenschaften verfügbar geben. Der Client erwartet, dass Anmeldeantworten als JSON-Objekte des Formulars zurückgegeben werden:
{
"authenticationToken": "<token>",
"user": {
"userId": "<userId>"
}
}
Die AppServiceLoginHandler.CreateToken()
-Methode enthält eine Zielgruppen- und einen Aussteller Parameter. Beide Parameter werden mithilfe des HTTPS-Schemas auf die URL Ihres Anwendungsstamms festgelegt. Ebenso sollten Sie secretKey- auf den Wert des Signaturschlüssels Ihrer Anwendung festlegen. Verteilen Sie den Signaturschlüssel nicht in einem Client, da er zum Abschlüsseln von Schlüsseln und zum Identitätswechsel von Benutzern verwendet werden kann. Sie können den Signaturschlüssel abrufen, während er in App Service gehostet wird, indem Sie auf die umgebungsvariable WEBSITE_AUTH_SIGNING_KEY
verweisen. Befolgen Sie bei Bedarf in einem lokalen Debugkontext die Anweisungen im Abschnitt lokales Debuggen mit Authentifizierung Abschnitt, um den Schlüssel abzurufen und als Anwendungseinstellung zu speichern.
Das ausgestellte Token kann auch andere Ansprüche und ein Ablaufdatum enthalten. Minimal muss das ausgestellte Token einen Antragstelleranspruch (Sub-) enthalten.
Sie können die Standardclient-loginAsync()
Methode unterstützen, indem Sie die Authentifizierungsroute überladen. Wenn der Client client.loginAsync('custom');
zum Anmelden aufruft, muss Ihre Route /.auth/login/custom
sein. Sie können die Route für den benutzerdefinierten Authentifizierungscontroller mit MapHttpRoute()
festlegen:
config.Routes.MapHttpRoute("custom", ".auth/login/custom", new { controller = "CustomAuth" });
Trinkgeld
Durch die Verwendung des loginAsync()
Ansatzes wird sichergestellt, dass das Authentifizierungstoken jedem nachfolgenden Aufruf des Diensts zugeordnet ist.
Abrufen von authentifizierten Benutzerinformationen
Wenn ein Benutzer von App Service authentifiziert wird, können Sie auf die zugewiesene Benutzer-ID und andere Informationen in Ihrem .NET-Back-End-Code zugreifen. Die Benutzerinformationen können zum Treffen von Autorisierungsentscheidungen im Back-End verwendet werden. Der folgende Code ruft die Benutzer-ID ab, die einer Anforderung zugeordnet ist:
// Get the SID of the current user.
var claimsPrincipal = this.User as ClaimsPrincipal;
string sid = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier).Value;
Die SID wird von der anbieterspezifischen Benutzer-ID abgeleitet und ist statisch für einen bestimmten Benutzer- und Anmeldeanbieter. Die SID ist null für ungültige Authentifizierungstoken.
Mit App Service können Sie auch bestimmte Ansprüche von Ihrem Anmeldeanbieter anfordern. Jeder Identitätsanbieter kann weitere Informationen über das Identitätsanbieter-SDK bereitstellen. Sie können beispielsweise die Facebook Graph-API für Freundesinformationen verwenden. Sie können Ansprüche angeben, die im Anbieterblatt im Azure-Portal angefordert werden. Für einige Ansprüche ist eine weitere Konfiguration mit dem Identitätsanbieter erforderlich.
Der folgende Code ruft die GetAppServiceIdentityAsync Erweiterungsmethode auf, um die Anmeldeinformationen abzurufen, die das Zugriffstoken enthalten, das erforderlich ist, um Anforderungen an die Facebook Graph-API zu stellen:
// Get the credentials for the logged-in user.
var credentials = await this.User.GetAppServiceIdentityAsync<FacebookCredentials>(this.Request);
if (credentials.Provider == "Facebook")
{
// Create a query string with the Facebook access token.
var fbRequestUrl = "https://graph.facebook.com/me/feed?access_token="
+ credentials.AccessToken;
// Create an HttpClient request.
var client = new System.Net.Http.HttpClient();
// Request the current user info from Facebook.
var resp = await client.GetAsync(fbRequestUrl);
resp.EnsureSuccessStatusCode();
// Do something here with the Facebook user information.
var fbInfo = await resp.Content.ReadAsStringAsync();
}
Fügen Sie eine using-Anweisung für System.Security.Principal
hinzu, um die GetAppServiceIdentityAsync Erweiterungsmethode bereitzustellen.
Einschränken des Datenzugriffs für autorisierte Benutzer
Im vorherigen Abschnitt haben wir gezeigt, wie die Benutzer-ID eines authentifizierten Benutzers abgerufen wird. Sie können den Zugriff auf Daten und andere Ressourcen basierend auf diesem Wert einschränken. Beispielsweise ist das Hinzufügen einer UserId-Spalte zu Tabellen und das Filtern der Abfrageergebnisse nach der Benutzer-ID eine einfache Möglichkeit, zurückgegebene Daten nur auf autorisierte Benutzer zu beschränken. Der folgende Code gibt Datenzeilen nur dann zurück, wenn die SID mit dem Wert in der Spalte "UserId" in der Tabelle "TodoItem" übereinstimmt:
// Get the SID of the current user.
var claimsPrincipal = this.User as ClaimsPrincipal;
string sid = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier).Value;
// Only return data rows that belong to the current user.
return Query().Where(t => t.UserId == sid);
Die Query()
-Methode gibt eine IQueryable
zurück, die von LINQ bearbeitet werden kann, um die Filterung zu verarbeiten.
Debuggen und Behandeln von Problemen mit dem .NET Server SDK
Azure App Service bietet verschiedene Debugging- und Problembehandlungstechniken für ASP.NET Anwendungen:
- Überwachen von Azure App Service-
- Aktivieren der Diagnoseprotokollierung in Azure App Service
- Problembehandlung für einen Azure App Service in Visual Studio
Protokollierung
Sie können in App Service-Diagnoseprotokolle schreiben, indem Sie das standardmäßige schreiben ASP.NET Ablaufverfolgung schreiben. Bevor Sie in die Protokolle schreiben können, müssen Sie die Diagnose in Ihrem Azure Mobile Apps-Back-End aktivieren.
So aktivieren Sie Die Diagnose und Schreiben in die Protokolle:
Führen Sie die Schritte in Aktivieren der Anwendungsprotokollierung (Windows)aus.
Fügen Sie die folgende using-Anweisung in Der Codedatei hinzu:
using System.Web.Http.Tracing;
Erstellen Sie einen Ablaufverfolgungs-Writer zum Schreiben aus dem .NET-Back-End in die Diagnoseprotokolle wie folgt:
ITraceWriter traceWriter = this.Configuration.Services.GetTraceWriter(); traceWriter.Info("Hello, World");
Veröffentlichen Sie Ihr Serverprojekt erneut, und greifen Sie auf das Azure Mobile Apps-Back-End zu, um den Codepfad mit der Protokollierung auszuführen.
Laden Sie die Protokolle herunter, und bewerten Sie sie, wie in Access-Protokolldateienbeschrieben.
Lokales Debuggen mit Authentifizierung
Sie können Ihre Anwendung lokal ausführen, um Änderungen zu testen, bevor Sie sie in der Cloud veröffentlichen. Drücken Sie für die meisten Azure Mobile Apps-Back-Ends F5- in Visual Studio. Bei der Verwendung der Authentifizierung gibt es jedoch einige zusätzliche Überlegungen.
Sie müssen über eine cloudbasierte mobile App verfügen, für die die App-Dienstauthentifizierung/Autorisierung konfiguriert ist, und Ihr Client muss den Cloudendpunkt als alternativer Anmeldehost angegeben haben. Die spezifischen Schritte, die erforderlich sind, finden Sie in der Dokumentation für Ihre Clientplattform.
Stellen Sie sicher, dass Ihr mobiles Back-End Microsoft.Azure.Mobile.Server.Authentication installiert hat. Fügen Sie dann in der OWIN-Startklasse Ihrer Anwendung Folgendes hinzu, nachdem MobileAppConfiguration
auf Ihre HttpConfiguration
angewendet wurde:
app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()
{
SigningKey = ConfigurationManager.AppSettings["authSigningKey"],
ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] },
ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] },
TokenHandler = config.GetAppServiceTokenHandler()
});
Im vorherigen Beispiel sollten Sie die authAudience- und authIssuer- Anwendungseinstellungen in Ihrer Web.config Datei so konfigurieren, dass es sich jeweils um die URL Ihres Anwendungsstamms mit dem HTTPS-Schema handeln soll. Ebenso sollten Sie authSigningKey- auf den Wert des Signaturschlüssels Ihrer Anwendung festlegen.
So rufen Sie den Signaturschlüssel ab:
- Navigieren Sie im Azure-Portal zu Ihrer App.
- Klicken Sie auf Tools>Kudu>Go.
- Klicken Sie auf der Kudu-Verwaltungswebsite auf Umgebung.
- Suchen Sie den Wert für
WEBSITE_AUTH_SIGNING_KEY
.
Verwenden Sie den Signierschlüssel für den authSigningKey Parameter in Ihrer lokalen Anwendungskonfiguration. Ihr mobiles Back-End ist jetzt ausgestattet, um Token zu validieren, wenn sie lokal ausgeführt werden, wodurch der Client das Token vom cloudbasierten Endpunkt abruft.