Die Installation von iOS Over The Air schlägt fehl, wenn die Plist-Datei durch die Formularauthentifizierung gesichert wird

Question

Wir versuchen die Installation von iOS Over The Air (OTA) auf unserer MVC3-Website mit Forms Authentication zu implementieren.

Die Installationsseite ist nur für authentifizierte Benutzer verfügbar. Außerdem möchten wir die tatsächlichen * .plist- und * .ipa-Dateien mithilfe der Formularauthentifizierung sperren. Dies soll verhindern, dass jemand versucht, die Datei direkt zu installieren, wenn sie die URL kennt.

Sobald wir alle Sicherheitsmaßnahmen installiert haben, können wir die App nicht mehr erfolgreich installieren. Der iPad-Browser gibt einen Fehler zurück: "Verbindung zu XXXX.com nicht möglich". Wenn wir allen Benutzern Zugriff auf den Ordner gewähren, in dem sich die Dateien befinden, wird die Installation erfolgreich abgeschlossen.

Hier liegt unser Problem. Es scheint , dass die OTA-Installationsanforderung das Authentifizierungscookie in seiner Anforderung nicht enthält. Momentan ist dies unsere beste Schätzung, was passiert, denn wenn wir allen Benutzern den Zugriff auf den Ordner erlauben, funktioniert alles gut. Außerdem haben wir die IIS-Protokolle überprüft, und es scheint auf dieselbe Schlussfolgerung zu zeigen.

Hier ist die zugehörige Protokolldatei Informationen:

2012-04-05 20:42:37 XXX.XXX.XXX.XXX GET/[WEBSEITE]/[SECURED FOLDER]/[FILE] .plist - 80 - XXX.XXX.XXX.XXX iTunes-iPad-M/5.0.1 + (32 GB) 302 0 0 46

2012-04-05 20:42:37 XXX.XXX.XXX.XXX GET/[ WEBSEITE]/login ReturnUrl =% 2f [WEBSEITE]% 2f [GESICHERTER ORDNER]% 2f [DATEI] .plist 80 - XXX.XXX.XXX.XXX iTunes-iPad-M/5.0.1 + (32GB) 200 0 0 15

Unsere Interpretation der Protokolldateien ist, dass die Anforderung an /[WEBSITE]/[SICHERE ORDNER]/[DATEI] .plist wird verweigert und eine 302 wird zurückgegeben. Die nächste protokollierte Anforderung ist die Anmeldeseite der Anwendung mit dem Pfad zur plist-Datei als Rückkehr-URL: /[WEBSEITE]/login ReturnUrl =% 2f [WEBSEITE]% 2f [GESICHERTER ORDNER]% 2f [DATEI] .plist

Irgendwelche Ideen, wie wir das überwinden können?

Answer 1

Am Ende war unser Verdacht richtig. Die OTA-Installationsanfrage enthält das Authentifizierungs-Cookie nicht in seiner Anfrage.

Um dies zu umgehen und trotzdem ein gewisses Maß an Authentifizierung zu haben, haben wir die Sicherheitseinschränkungen für Installationsdateien entfernt. Wir fügten dann einen einmaligen Verifikationsschlüssel für die Verknüpfung zum OTA-Standort hinzu.