Aggiungi intestazioni delle richieste HTTP aggiuntive

Pavol drotar
Pavol Drotar

Le richieste HTTP contengono intestazioni come User-Agent o Content-Type. Oltre alle intestazioni collegate dai browser, le app per Android potrebbero aggiungere altre intestazioni, come Cookie o Referrer tramite l'elemento aggiuntivo EXTRA_HEADERS Intent. Per motivi di sicurezza, Chrome filtra alcune delle intestazioni aggiuntive in base a come e dove viene avviato un intent.

Le richieste cross-origin richiedono un ulteriore livello di sicurezza, poiché il client e il server non sono di proprietà della stessa parte. Questa guida illustra l'avvio di queste richieste tramite le schede personalizzate di Chrome, ovvero gli intent avviati da app che aprono un URL nella scheda del browser. Fino a Chrome 83, gli sviluppatori potevano aggiungere qualsiasi intestazione al lancio di una scheda personalizzata. A partire dalla versione 83 in poi, Chrome ha iniziato a filtrare tutte le intestazioni multiorigine approvate, poiché le intestazioni non approvate hanno rappresentato un rischio per la sicurezza. A partire da Chrome 86, è possibile collegare intestazioni non approvate elencate alle richieste multiorigine, quando il server e il client sono collegati tramite un link asset digitale. Questo comportamento è riassunto nella seguente tabella:

Versione di Chrome Intestazioni CORS consentite
precedenti a Chrome 83 elenco approvato, non-presentato approvato
Da Chrome 83 a Chrome 85 in elenco approvato
da Chrome 86 in poi nell'elenco approvato, non nell'elenco approvato quando viene configurato un link agli 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 non approvate e non approvate. Puoi passare direttamente ad Aggiungere intestazioni aggiuntive agli intent di schede personalizzate per il codice.

Contesto

Intestazioni delle richieste CORS incluse nell'approvazione e non in elenco non approvate

La condivisione delle risorse tra origini (CORS) consente a un'applicazione web di un'origine di richiedere risorse di origini diverse. L'elenco delle intestazioni CORS-approvelisting viene gestito in HTML Standard. Nella tabella successiva sono riportati alcuni esempi di intestazioni incluse nell'elenco approvato:

Header Descrizione
accetta-lingua pubblicizza linguaggi naturali che il cliente comprende
lingua dei contenuti descrive il linguaggio destinato al pubblico attuale
tipo di contenuti indica il tipo multimediale della risorsa

Tabella 2. Esempio di intestazioni CORS incluse nell'approvazione.

Le intestazioni approvate dall'elenco sono considerate sicure perché non contengono informazioni sensibili sull'utente ed è improbabile che causino operazioni potenzialmente dannose sul server.

Nella seguente tabella sono riportati alcuni esempi di intestazioni non incluse nell'elenco di approvazione:

Header Descrizione
token di connessione autentica il client presso un server
origin indica l'origine della richiesta
biscotto contiene i cookie impostati dal server

Tabella 3. Esempio di intestazioni CORS non approvate.

Il collegamento di intestazioni non approvate elencate alle richieste CORS è sconsigliato dallo standard HTML e i server presumono che le richieste multiorigine contengano solo intestazioni approvatelist. L'invio di intestazioni non approvate elencate da domini multiorigine consentirebbe ad app dannose di terze parti di creare intestazioni che utilizzino in modo improprio i cookie dell'utente che Chrome (o un altro browser) archivia e allega alle richieste. I cookie potrebbero autenticare transazioni server dannose che altrimenti non sarebbero possibili.

Collegamento delle intestazioni approvate CORS alle richieste di schede personalizzate

Le schede personalizzate sono un modo speciale per lanciare pagine web in una scheda del browser personalizzata. Gli intent delle schede personalizzate possono essere creati utilizzando CustomTabsIntent.Builder(). Puoi anche collegare le intestazioni a questi intent utilizzando un 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 allegare in qualsiasi momento le intestazioni della lista approvata alle richieste CORS delle schede personalizzate. Tuttavia, Chrome filtra le intestazioni non approvate per impostazione predefinita. Anche se altri browser possono avere un comportamento diverso, gli sviluppatori dovrebbero aspettarsi che le intestazioni non approvate elencate vengano bloccate in generale.

Il modo supportato per includere intestazioni non approvate nelle schede personalizzate consiste innanzitutto nel verificare la connessione multiorigine utilizzando un link di accesso digitale. La sezione successiva mostra come impostarli e avviare un intent Schede personalizzate con le intestazioni richieste.

Aggiunta di intestazioni aggiuntive agli intent di schede personalizzate

Per consentire il trasferimento di intestazioni non approvate dall'elenco di utenti autorizzati tramite gli intent della scheda personalizzata, è necessario impostare un collegamento degli asset digitali tra l'applicazione web e l'applicazione Android per verificare che l'autore possieda entrambe le applicazioni.

Segui la guida ufficiale per configurare un link agli asset digitali. Per la relazione link, utilizza "delegate_permission/common.use_as_origin"" che indica che entrambe le app appartengono alla stessa origine una volta verificato il collegamento.

Crea intent di scheda personalizzata con intestazioni aggiuntive

Esistono diversi modi per creare un intent Schede personalizzate. Puoi usare il builder disponibile 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

Una connessione Schede personalizzate viene utilizzata per configurare un CustomTabsSession tra l'app e la scheda di Chrome. La sessione serve per verificare che l'app e l'app web appartengano alla stessa origine. La verifica viene eseguita solo se i link agli asset digitali sono stati configurati correttamente.

Ti invitiamo a chiamare CustomTabsClient.warmup(). Consente all'applicazione browser di pre-inizializzare in background e di velocizzare il processo di apertura dell'URL.

MULTI_LINE_CODE_PLACEHOLDER_3

Impostazione di un callback che avvii l'intent dopo la convalida

CustomTabsCallback è stato inserito nella sessione. Abbiamo configurato il suo onRelationshipValidationResult() in modo da lanciare il CustomTabsIntent creato in precedenza una volta completata la verifica dell'origine.

MULTI_LINE_CODE_PLACEHOLDER_4

Associa la connessione al servizio delle schede personalizzate

L'associazione del servizio avvierà il servizio e alla fine verrà chiamato il onCustomTabsServiceConnected() della connessione. Non dimenticare di svincolare il servizio in modo appropriato. L'associazione e lo svincolo vengono generalmente eseguiti 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

Puoi trovare ulteriori dettagli sul servizio Schede personalizzate qui. Consulta il repository GitHub android-browser-helper per un esempio di app funzionante.

Riepilogo

Questa guida ha dimostrato come aggiungere intestazioni arbitrarie alle richieste CORS di schede personalizzate. Le intestazioni approvatelist possono essere collegate a ogni richiesta CORS di schede personalizzate. Le intestazioni non approvate nell'elenco sono generalmente considerate non sicure nelle richieste CORS e Chrome le filtra per impostazione predefinita. Il loro collegamento è consentito solo per client e server con la stessa origine, verificati tramite un link asset digitale.