Ich habe eine Anwendung geschrieben, ein automatisches VPN-Bereitstellungs-Webportal in Python für Apple-Geräte.
Was mich stört, ist ein Unterschied im Verhalten zwischen dem Test- und dem Produktionsserver; ersterer verwendet Apache, während letzterer verwendet lighthttpd.
Wenn die Datei geöffnet und „ausgeführt“ wird, werden beispielsweise automatisch die SysPrefs geöffnet, was bei Apache nicht der Fall ist lighhttpd..mobileconfig
Mir ist bereits aufgefallen, lighhtpddass es hinsichtlich korrekter Definitionen viel laxer zugeht . Das Problem besteht jedoch darin, dass Safari Dateien mit ordnungsgemäß Content-Typelädt und „automatisch ausführt“, während dies bei nicht der Fall ist ..mobileconfiglighthttpdApache
Was mich weiter ärgert ist, dass ich auf beiden Servern das Entsprechende nicht richtig definiert habe, mime.typeund zwar wie folgt:
lighthttpd.conf
$HTTP["url"] =~ "\.mobileconfig$" {
setenv.add-response-header = ( "Content-Disposition" => "attachment" )
mimetype.assign = (".mobileconfig" => "application/x-apple-aspen-config",
"" => "application/octet-stream")
}
Wie in Apache lautet es:
dovpn.conf (virtueller Host)
AddType application/x-apple-aspen-config .mobileconfig
Der erste Hinweis auf einen Unterschied scheint tatsächlich aus dieser add-response-headerRichtlinie in zu stammen lighthttpd.
Im generierten HTML habe ich:
a download="profile.mobileconfig" href="../upload/8bd16b26-1473-4994-9803-8268a372cd0d.mobileconfig" type="application/octet-stream">Download automatic profile/a
und ich führe einen automatischen Download davon über Javascript durch
//If in Safari - download via virtual link click
if (window.downloadFile.isSafari) {
//Creating new link node.
var link = document.createElement('a');
link.href = sUrl;
if (link.download !== undefined) {
//Set HTML5 download attribute. This will prevent file from opening if supported.
var fileName = sUrl.substring(sUrl.lastIndexOf('/') + 1, sUrl.length);
link.download = fileName;
}
//Dispatching click event.
if (document.createEvent) {
var e = document.createEvent('MouseEvents');
e.initEvent('click', true, true);
link.dispatchEvent(e);
return true;
}
}
Der Inhalt der generierten Seite hat ebenfalls nur als Content-Type:
Content-Type: text/html\n\n
sowohl in Apache als auch in lighthttpd. Ich habe das Netzwerk durchsucht und es gibt keine offensichtlichen Änderungen am Content-Type über lighthttpd.
Kann ich eine ähnliche Funktionalität wie setenv.add-response-headermit Apache replizieren?
Ich habe bereits versucht, dem Apache-Host Folgendes hinzuzufügen:
<Files "*.mobileconfig">
Header set Content-Disposition attachment
</Files>
Und
SetEnvIf Request_URI "\.mobileconfig$" change_header
Header set Content-Disposition attachment env=change_header
Und
SetEnvIf Request_URI "\.mobileconfig$" change_header
Header always add "Content-Disposition" "attachment" env=change_header
Und
<Files "*.mobileconfig">
Header append Content-Disposition attachment
</Files>
Ich habe auch versucht, im aktuellen Verzeichnis eine .htaccessDatei mit folgendem Inhalt zu erstellen:
<IfModule mod_headers.c>
<FilesMatch "\.mobileconfig$">
ForceType application/octet-stream
Header append Content-Disposition "attachment"
Allow from all
</FilesMatch>
</IfModule>
Und
<IfModule mod_headers.c>
<FilesMatch "\.mobileconfig$">
ForceType application/octet-stream
Header add Content-Disposition "attachment"
Allow from all
</FilesMatch>
</IfModule>
In beiden Fällen attachmenthabe ich außerdem auch verwendet "attachment".
Bitte beachten Sie, dass mod_headers in Apache/Debian 9 standardmäßig aktiv ist und keine dieser Alternativen funktioniert hat.
Eigentlich fällt mir gerade ein, lighthttpddass es HTTP und ApacheHTTPS verwendet. Ich habe lighthttpd mit HTTPS getestet und es funktioniert auch über HTTPS, Apache hingegen nicht.
Ausgabe curl -k -I https://localhost/cgi-bin/vpn.pyim Lighthttpd-Server:
HTTP/1.1 200 OK
Content type: text/html
Content-Length: 331
Date: Thu, 01 Jun 2017 09:03:26 GMT
Server: lighttpd/1.4.45
Ausgabe curl -k -I https://localhost/cgi-bin/vpn.pyim Apache-Server:
HTTP/1.1 200 OK
Date: Thu, 01 Jun 2017 09:05:25 GMT
Server: Apache
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Content-Type: text/html; charset=UTF-8
Darüber hinaus gilt auch in Apache:
$curl -k -I https://localhost/download/xxx.mobileconfig
HTTP/1.1 200 OK
Date: Thu, 01 Jun 2017 09:13:35 GMT
Server: Apache
Last-Modified: Thu, 01 Jun 2017 03:08:57 GMT
ETag: "1f3b-550dd5b89d8df"
Accept-Ranges: bytes
Content-Length: 7995
X-Frame-Options: sameorigin
Content-Disposition: attachment
Content-Type: application/x-apple-aspen-config
Wenn ich Safari verwende->Entwickeln->Webinspektor anzeigen->Debugger->auf die Hauptseite klicke->Als Curl kopieren, bekomme ich nur „curl“ angezeigt.https://xxxx/cgi-bin/vpn.py'-Xnull' beim Einfügen.
Ich habe auch versucht, es zu deaktivieren X-Frame-Options: "sameorigin", aber es hat keinen Unterschied gemacht (ich wusste, dass es ein Glücksspiel war).
Antwort1
Es scheint, dass durch die Verwendung der .htaccessDatei das Problem des Hinzufügens der Content-Disposition zu den Headern gelöst wurde.
Für das Problem der Replikation der Funktionalität und die zusätzliche Komplexität bei der Fehlerbehebung und den Tests scheint es jedoch eine andere Erklärung zu geben.
Es scheint, dass sowohl in der neuesten Beta als auch in der aktuellen Version des Sierra-Updates .mobileconfigDateien aus Sicherheitsgründen aus der Safari-Liste der „sicheren“ Dateien zum Öffnen entfernt wurden.
Ich habe gestern (oder vorgestern) das MacOS bei der Arbeit und heute zu Hause aktualisiert und kann weder .mobileconfigauf dem Produktions- noch auf dem Vorproduktionssystem Dateien mehr automatisch öffnen.
Ich habe gerade mein iPhone auf iOS 10.3.3 Beta aktualisiert und es scheint auch die Tendenz von Apple zu bestätigen, .mobileconfigProvisioning-Dateien als potenziell gefährlich zu behandeln. Wenn Sie nun auf eine solche Datei klicken, wird Ihnen eine neue Warnung angezeigt:
Diese Website versucht, die Einstellungen zu öffnen, um Ihnen ein Konfigurationsprofil anzuzeigen. Möchten Sie dies zulassen?
Ignorieren - Zulassen