Le richieste HTTP contengono intestazioni come User-Agent o Content-Type. A parte le intestazioni allegate da
browser, le app per Android potrebbero aggiungere altre intestazioni, come Cookie o Referrer tramite
EXTRA_HEADERS Intent extra. Per motivi di sicurezza, Chrome filtra alcune intestazioni aggiuntive
a seconda di come e dove
viene lanciato un intent.
Le richieste multiorigine richiedono un livello di sicurezza aggiuntivo, in quanto client e server sono non di proprietà della stessa parte. Questa guida illustra l'avvio di queste richieste tramite Chrome schede personalizzate, ovvero intent avviati da app che aprono un URL nella scheda del browser. Fino a Chrome 83, gli sviluppatori potevano aggiungere qualsiasi intestazione all'avvio di una scheda personalizzata. A partire dalla versione 83, Chrome ha iniziato a filtrare tutti tranne le intestazioni multiorigine approvate, poiché intestazioni non approvate rappresentavano un rischio per la sicurezza. A partire da Chrome 86, puoi collegare intestazioni non approvate Richieste multiorigine, quando il server e il client sono collegati tramite un collegamento ad asset digitali. Questo comportamento è riassunto nella seguente tabella:
| Versione di Chrome | Intestazioni CORS consentite |
|---|---|
| prima di Chrome 83 | approvato, non approvato |
| Da Chrome 83 a Chrome 85 | inserito in una lista di approvazione |
| a partire da Chrome 86 | approvato, non approvato quando è configurato un link ad asset digitali |
Tabella 1: Filtro delle intestazioni CORS non approvate.
Questo articolo spiega come configurare una connessione verificata tra il server e il client e come utilizzarla per inviare intestazioni HTTP incluse e non approvate. Puoi passare direttamente a Aggiunta di intestazioni aggiuntive agli intent di schede personalizzate per il codice.
Sfondo
Intestazioni delle richieste CORS approvate e non approvate
La condivisione delle risorse tra origini (CORS) consente a un'applicazione web da un'origine di richiedere di risorse di origine diversa. L'elenco delle intestazioni CORS-approvate viene mantenuto nella HTML standard. Le intestazioni di esempio approvate sono mostrate nella tabella successiva:
| Header | Descrizione |
|---|---|
| accept-language | pubblicizza lingue naturali che il cliente comprende |
| content-language | descrive il linguaggio destinato al pubblico attuale |
| tipo di contenuti | indica il tipo multimediale della risorsa |
Tabella 2: Esempi di intestazioni CORS approvate.
Le intestazioni approvate sono considerate sicure in quanto non contengono dati sensibili informazioni sugli utenti ed è improbabile che causino l'esecuzione di operazioni potenzialmente dannose per il server.
Nella tabella seguente sono riportati alcuni esempi di intestazioni non approvate:
| Header | Descrizione |
|---|---|
| bearer-token | autentica il client su un server |
| origine | indica l'origine della richiesta |
| biscotto | contiene i cookie impostati dal server |
Tabella 3: Esempi di intestazioni CORS non approvate.
Il collegamento di intestazioni non approvate alle richieste CORS è sconsigliato dallo standard HTML e dai server presupporre che le richieste multiorigine contengano solo intestazioni di cui all'elenco approvato. Invio di intestazioni non approvate da domini multiorigine consentirebbe ad app dannose di terze parti di creare intestazioni che abusano dell’utente Cookie che Chrome (o un altro browser) archivia e allega alle richieste. I cookie potrebbero di autenticare le transazioni server dannose che altrimenti non sarebbero possibili.
Collegamento delle intestazioni CORS approvate alle richieste di schede personalizzate
Le schede personalizzate sono un modo speciale per aprire le pagine web in una scheda del browser personalizzata. Scheda personalizzata
gli intent possono essere creati utilizzando CustomTabsIntent.Builder(). Puoi anche allegare intestazioni a questi
intent che utilizzano Bundle con il flag Browser.EXTRA_HEADERS:
CustomTabsIntent intent = new CustomTabsIntent.Builder(session).build();
Bundle headers = new Bundle();
headers.putString("bearer-token", "Some token");
headers.putString("redirect-url", "Some redirect url");
intent.intent.putExtra(Browser.EXTRA_HEADERS, headers);
intent.launchUrl(Activity.this, Uri.parse("http://www.google.com"));
Possiamo sempre allegare le intestazioni approvate alle richieste CORS delle schede personalizzate. Tuttavia, Chrome filtra intestazioni non approvate per impostazione predefinita. Sebbene altri browser possano avere comportamenti diversi, gli sviluppatori devono aspettarsi il blocco in generale delle intestazioni non approvate.
Il modo supportato per includere le intestazioni non approvate nelle schede personalizzate consiste nel verificare connessione multiorigine mediante un Digital Access Link. La sezione successiva mostra come impostarli e avviare un intent di schede personalizzate con le intestazioni richieste.
Aggiunta di intestazioni extra agli intent di schede personalizzate
Configurare i collegamenti per gli asset digitali
Per consentire il trasferimento delle intestazioni non approvate tramite gli intent della scheda personalizzata, è necessario impostare creare un collegamento di risorse digitali tra l'applicazione Android e l'applicazione web per verificare che l'autore possiede entrambe le applicazioni.
Segui la guida ufficiale per configurare un link a una risorsa digitale. Per la relazione di collegamento, utilizza "delegate_permission/common.use_as_origin"' che indica che entrambe le app appartengono alla stessa una volta verificato il collegamento.
Crea intent di scheda personalizzata con intestazioni aggiuntive
Esistono diversi modi per creare un intent delle schede personalizzate. Puoi usare lo strumento di creazione in androidX aggiungendo la libreria alle dipendenze della build:
MULTI_LINE_CODE_PLACEHOLDER_1
Crea l'intent e aggiungi altre intestazioni:
MULTI_LINE_CODE_PLACEHOLDER_2
Imposta una connessione a schede personalizzate per convalidare il link agli asset
Viene utilizzata una connessione Schede personalizzate per configurare un CustomTabsSession tra l'app e la
Scheda Chrome. Abbiamo bisogno della sessione per verificare che l'app e l'app web appartengano alla stessa origine.
La verifica ha esito positivo solo se i link agli asset digitali sono stati configurati correttamente.
Ti consigliamo di chiamare CustomTabsClient.warmup(). Consente all'applicazione del browser di
vengono pre-inizializzati in background e velocizzano il processo di apertura dell'URL.
MULTI_LINE_CODE_PLACEHOLDER_3
Configura un callback che avvii l'intent dopo la convalida
CustomTabsCallback è stato trasmesso nella sessione. Abbiamo configurato
onRelationshipValidationResult() per avviare CustomTabsIntent creato in precedenza
una volta completata la verifica dell'origine.
MULTI_LINE_CODE_PLACEHOLDER_4
Associa la connessione al servizio di schede personalizzate
L'associazione del servizio avvia il servizio e il valore onCustomTabsServiceConnected() della connessione
che prima o poi verrà chiamato. Non dimenticare di slegare in modo appropriato il servizio. Associazione e svincolo
Viene comunemente eseguita nei metodi del ciclo di vita delle attività onStart() e onStop().
// Bind the custom tabs service connection.
// Call this in onStart()
CustomTabsClient.bindCustomTabsService(this,
CustomTabsClient.getPackageName(MainActivity.this, null), connection);
// …
// Unbind the custom tabs service.
// Call this in onStop().
unbindService(connection);
Codice dell'applicazione demo
Per ulteriori dettagli sul servizio Schede personalizzate, fai clic qui. Consulta le Repository GitHub android-browser-helper per un'app funzionante di esempio.
Riepilogo
Questa guida ha dimostrato come aggiungere intestazioni arbitrarie alle richieste CORS di schede personalizzate. le intestazioni approvate possono essere collegate a ogni richiesta CORS di schede personalizzate. Le intestazioni non approvate vengono generalmente considerati non sicuri nelle richieste CORS e Chrome le filtra per impostazione predefinita. Il collegamento è consentito solo per client e server della stessa origine, verificati da un collegamento a asset digitali.