Eu escrevi um aplicativo, um portal web de provisionamento automático de VPN em python para dispositivos Apple.
O que me incomoda é a diferença de comportamento entre o servidor de teste e o servidor de produção; o primeiro está usando Apache, enquanto o último está usando lighthttpd.
No lighhttpdarquivo .mobileconfigé aberto e "executado", por exemplo, ele abre SysPrefs automaticamente, enquanto no Apache isso não está acontecendo.
Já percebi lighhtpdque é muito mais negligente em relação Content-Typeàs definições adequadas, porém o problema em questão é que o Safari irá carregar e "executar automaticamente" .mobileconfigos arquivos corretamente, lighthttpdenquanto o mesmo não acontece com Apache.
O que me irrita ainda mais é que em ambos os servidores eu defini corretamente o correspondente mime.typecomo em:
lighthttpd.conf
$HTTP["url"] =~ "\.mobileconfig$" {
setenv.add-response-header = ( "Content-Disposition" => "attachment" )
mimetype.assign = (".mobileconfig" => "application/x-apple-aspen-config",
"" => "application/octet-stream")
}
Como no Apache é:
dovpn.conf (vhost)
AddType application/x-apple-aspen-config .mobileconfig
A primeira pista de uma diferença parece, na verdade, resultar dessa add-response-headerdirectiva em lighthttpd.
No HTML gerado, tenho:
a download="profile.mobileconfig" href="../upload/8bd16b26-1473-4994-9803-8268a372cd0d.mobileconfig" type="application/octet-stream">Download automatic profile/a
e faço um download automático disso via 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;
}
}
O conteúdo da página de geração também possui apenas como Content-Type:
Content-Type: text/html\n\n
tanto no Apache quanto no lighthttpd. Farejei a transmissão e não há alterações aparentes feitas no Content-Type por meio de lighthttpd.
Serei capaz de replicar funcionalidades semelhantes setenv.add-response-headercom o Apache?
Já tentei adicionar ao host Apache:
<Files "*.mobileconfig">
Header set Content-Disposition attachment
</Files>
e
SetEnvIf Request_URI "\.mobileconfig$" change_header
Header set Content-Disposition attachment env=change_header
e
SetEnvIf Request_URI "\.mobileconfig$" change_header
Header always add "Content-Disposition" "attachment" env=change_header
e
<Files "*.mobileconfig">
Header append Content-Disposition attachment
</Files>
Também tentei, no diretório real, criar um .htaccessarquivo com:
<IfModule mod_headers.c>
<FilesMatch "\.mobileconfig$">
ForceType application/octet-stream
Header append Content-Disposition "attachment"
Allow from all
</FilesMatch>
</IfModule>
e
<IfModule mod_headers.c>
<FilesMatch "\.mobileconfig$">
ForceType application/octet-stream
Header add Content-Disposition "attachment"
Allow from all
</FilesMatch>
</IfModule>
Em ambos os casos, além disso attachment, também usei "attachment".
Observe que mod_headers está ativo por padrão no Apache/Debian 9 e nenhuma dessas alternativas funcionou.
Na verdade, acabei de lembrar lighthttpdque está usando HTTP e ApacheHTTPS. Eu testei lighthttpd com HTTPS e também funciona em HTTPS, enquanto o Apache não.
Saída do curl -k -I https://localhost/cgi-bin/vpn.pyservidor 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
Saída curl -k -I https://localhost/cgi-bin/vpn.pyno 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
Além disso, também no 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
Usar Safari->Desenvolver->Mostrar web Inspector->Debugger->clicar na página principal->Copiar como curl só me retorna "curl 'https://xxxx/cgi-bin/vpn.py' -Xnull" ao colar.
Também tentei desativar X-Frame-Options: "sameorigin"e não fez diferença (eu sabia que era um tiro no escuro)
Responder1
Parece que o uso do .htaccessarquivo resolveu o problema de adicionar aos cabeçalhos o Content-Disposition.
No entanto, o problema de replicar a funcionalidade e a complexidade adicional na depuração e nos testes --- parece ter outra explicação.
Parece que tanto na versão beta mais recente quanto na versão atual dos .mobileconfigarquivos de atualização do Sierra foram retirados da lista de arquivos "seguros" do Safari para abertura por motivos de segurança.
Atualizei ontem (ou anteontem) o MacOS no trabalho, hoje em casa e não consigo mais fazer com que .mobileconfigos arquivos do sistema de produção ou de pré-produção abram automaticamente.
Acabei de atualizar meu iPhone para iOS 10.3.3 beta, e isso também parece confirmar a tendência da Apple de tratar o .mobileconfigprovisionamento de arquivos como potencialmente perigosos. Agora, ao clicar em tal arquivo, você recebe um novo aviso:
Este site está tentando abrir Configurações para mostrar um perfil de configuração. Você quer permitir isto?
Ignorar - Permitir