He escrito una aplicación, un portal web de aprovisionamiento automático de VPN en Python para dispositivos Apple.
Lo que me molesta es la diferencia de comportamiento entre el servidor de prueba y el de producción; el primero usa Apache, mientras que el segundo usa lighthttpd.
En lighhttpdel .mobileconfigarchivo se abre y se "ejecuta", por ejemplo, abre SysPrefs automáticamente, mientras que en Apache eso no sucede.
Ya he notado lighhtpdque es mucho más laxo con respecto a Content-Typelas definiciones adecuadas, sin embargo, el problema en cuestión es que Safari cargará y "autoejecutará" .mobileconfigarchivos correctamente, lighthttpdmientras que no sucede lo mismo con Apache.
Lo que más me molesta es que en ambos servidores he definido correctamente el correspondiente mime.typecomo en:
luzhttpd.conf
$HTTP["url"] =~ "\.mobileconfig$" {
setenv.add-response-header = ( "Content-Disposition" => "attachment" )
mimetype.assign = (".mobileconfig" => "application/x-apple-aspen-config",
"" => "application/octet-stream")
}
Como en Apache es:
dovpn.conf (vhost)
AddType application/x-apple-aspen-config .mobileconfig
En realidad, el primer indicio de una diferencia parece surgir de esa add-response-headerDirectiva de lighthttpd.
En el HTML generado, tengo:
a download="profile.mobileconfig" href="../upload/8bd16b26-1473-4994-9803-8268a372cd0d.mobileconfig" type="application/octet-stream">Download automatic profile/a
y hago una descarga automática de eso a través de Javascript
//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;
}
}
El contenido de la página de generación también solo tiene como Tipo de contenido:
Content-Type: text/html\n\n
tanto en Apache como en lighthttpd. Olisqueé el cable y no se han realizado cambios aparentes en el tipo de contenido a través de lighthttpd.
¿Podré replicar una funcionalidad similar setenv.add-response-headercon Apache?
Ya intenté agregar al host Apache:
<Files "*.mobileconfig">
Header set Content-Disposition attachment
</Files>
y
SetEnvIf Request_URI "\.mobileconfig$" change_header
Header set Content-Disposition attachment env=change_header
y
SetEnvIf Request_URI "\.mobileconfig$" change_header
Header always add "Content-Disposition" "attachment" env=change_header
y
<Files "*.mobileconfig">
Header append Content-Disposition attachment
</Files>
También intenté, en el directorio real, crear un .htaccessarchivo con:
<IfModule mod_headers.c>
<FilesMatch "\.mobileconfig$">
ForceType application/octet-stream
Header append Content-Disposition "attachment"
Allow from all
</FilesMatch>
</IfModule>
y
<IfModule mod_headers.c>
<FilesMatch "\.mobileconfig$">
ForceType application/octet-stream
Header add Content-Disposition "attachment"
Allow from all
</FilesMatch>
</IfModule>
En ambos casos, además attachment, también usé "attachment".
Tenga en cuenta que mod_headers está activo de forma predeterminada en Apache/Debian 9 y ninguna de estas alternativas funcionó.
En realidad, acabo de recordar lighthttpdque estoy usando HTTP y ApacheHTTPS. Lo probé lighthttpd con HTTPS y también funciona a través de HTTPS, mientras que Apache no.
Salida del curl -k -I https://localhost/cgi-bin/vpn.pyservidor in lighthttpd:
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
Salida de curl -k -I https://localhost/cgi-bin/vpn.pyen el servidor Apache:
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
Además, en Apache también:
$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
Usar Safari->Desarrollar->Mostrar inspector web->Depurador->hacer clic en la página principal->Copiar como curl solo me devuelve "curl 'https://xxxx/cgi-bin/vpn.py' -Xnull" al pegar.
También intenté desactivarlo X-Frame-Options: "sameorigin"y no hizo ninguna diferencia (sabía que era una posibilidad remota)
Respuesta1
Parece que el uso del .htaccessarchivo resolvió el problema de agregar a los encabezados la disposición de contenido.
Sin embargo, el problema de replicar la funcionalidad y la complejidad adicional en la depuración y las pruebas parece tener otra explicación.
Parece que tanto en la última versión beta como en la actual de la actualización de Sierra, .mobileconfiglos archivos se eliminaron de la lista de Safari de archivos "seguros" para abrir por razones de seguridad.
Actualicé ayer (o anteayer) MacOS en el trabajo, hoy en casa, y ya no puedo hacer que .mobileconfiglos archivos ni en el sistema de producción ni en el de preproducción se abran automáticamente.
Acabo de actualizar mi iPhone a iOS 10.3.3 beta y también parece confirmar la tendencia de Apple a tratar el .mobileconfigaprovisionamiento de archivos como potencialmente peligrosos. Ahora, al hacer clic en dicho archivo, se le presenta una nueva advertencia:
Este sitio web está intentando abrir Configuración para mostrarle un perfil de configuración. ¿Quieres permitir esto?
Ignorar - Permitir