HTTP-verzoeken bevatten headers zoals User-Agent of Content-Type. Afgezien van headers die door browsers zijn bijgevoegd, kunnen Android-apps extra headers toevoegen, zoals Cookie of Referrer via de EXTRA_HEADERS Intent extra. Om veiligheidsredenen filtert Chrome enkele van de extra headers, afhankelijk van hoe en waar een intentie wordt gelanceerd.
Cross-originele verzoeken vereisen een extra beveiligingslaag omdat de client en server geen eigendom zijn van dezelfde partij. In deze handleiding wordt het starten van dergelijke verzoeken besproken via aangepaste Chrome-tabbladen , dat wil zeggen intenties die worden gestart vanuit apps die een URL openen op het browsertabblad. Tot Chrome 83 konden ontwikkelaars headers toevoegen bij het starten van een aangepast tabblad. Vanaf versie 83 begon Chrome alle cross-origin-headers op de goedgekeurde lijst te filteren, omdat niet-goedgekeurde headers een beveiligingsrisico vormden. Vanaf Chrome 86 is het mogelijk om niet-goedgekeurde headers toe te voegen aan cross-origin-verzoeken, wanneer de server en client gerelateerd zijn met behulp van een digitale asset-link . Dit gedrag wordt samengevat in de volgende tabel:
| Chrome-versie | CORS-headers toegestaan |
|---|---|
| vóór Chrome 83 | goedgekeurd, niet-goedgekeurd |
| Chroom 83 tot Chroom 85 | goedgekeurd |
| vanaf Chrome 86 en later | goedgekeurd, niet-goedgekeurd wanneer een koppeling met digitale activa is ingesteld |
Tabel 1.: Filteren van niet-goedgekeurde CORS-headers.
Dit artikel laat zien hoe u een geverifieerde verbinding tussen de server en de client instelt en deze gebruikt om zowel goedgekeurde als niet-goedgekeurde http-headers te verzenden. U kunt doorgaan naar Extra kopteksten toevoegen aan aangepaste tabbladintenties voor de code.
Achtergrond
goedgekeurde versus niet-goedgekeurde CORS-verzoekheaders
Cross-Origin Resource Sharing (CORS) zorgt ervoor dat een webapplicatie van de ene oorsprong bronnen van een andere oorsprong kan opvragen. De lijst met door CORS goedgekeurde headers wordt bijgehouden in de HTML-standaard . In de volgende tabel worden voorbeelden van goedgekeurde kopteksten weergegeven:
| Koptekst | Beschrijving |
|---|---|
| accept-taal | maakt reclame voor natuurlijke talen die de klant begrijpt |
| inhoud-taal | beschrijft taal bedoeld voor het huidige publiek |
| inhoudstype | geeft het mediatype van de bron aan |
Tabel 2.: Voorbeeld van goedgekeurde CORS-headers.
De goedgekeurde headers worden als veilig beschouwd omdat ze geen gevoelige gebruikersinformatie bevatten en het onwaarschijnlijk is dat de server potentieel schadelijke bewerkingen zal uitvoeren.
Voorbeelden van niet-goedgekeurde headers worden weergegeven in de volgende tabel:
| Koptekst | Beschrijving |
|---|---|
| token aan toonder | authenticeert de client op een server |
| oorsprong | geeft de herkomst van het verzoek aan |
| koekje | bevat cookies die door de server zijn ingesteld |
Tabel 3.: Voorbeeld van niet-goedgekeurde CORS-headers.
Het toevoegen van niet-goedgekeurde headers aan CORS-verzoeken wordt ontmoedigd door de HTML-standaard en servers gaan ervan uit dat cross-origin-aanvragen alleen goedgekeurde headers bevatten. Door niet-goedgekeurde headers vanuit cross-origin-domeinen te verzenden, kunnen kwaadwillende apps van derden headers maken die misbruik maken van gebruikerscookies die Chrome (of een andere browser) opslaat en aan verzoeken koppelt. De cookies kunnen kwaadaardige servertransacties verifiëren die anders niet mogelijk zouden zijn.
Door CORS goedgekeurde headers toevoegen aan verzoeken voor aangepaste tabbladen
Aangepaste tabbladen zijn een speciale manier om webpagina's te starten op een aangepast browsertabblad. Aangepaste tabbladintenties kunnen worden gemaakt met CustomTabsIntent.Builder() . U kunt ook headers aan deze intenties koppelen met behulp van een Bundle met de vlag 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"));
We kunnen altijd goedgekeurde headers toevoegen aan CORS-verzoeken op aangepaste tabbladen. Chrome filtert echter standaard niet-goedgekeurde headers. Hoewel andere browsers zich mogelijk anders gedragen, mogen ontwikkelaars verwachten dat niet-goedgekeurde headers in het algemeen worden geblokkeerd.
De ondersteunde manier om niet-goedgekeurde headers op te nemen in aangepaste tabbladen is om eerst de cross-origin-verbinding te verifiëren met behulp van een digitale toegangslink. In de volgende sectie ziet u hoe u deze instelt en een aangepaste tabbladen-intentie start met de vereiste headers.
Extra kopteksten toevoegen aan aangepaste tabbladintenties
Stel digitale asset-koppelingen in
Om ervoor te zorgen dat niet-goedgekeurde headers via de intenties van aangepaste tabbladen worden doorgegeven, is het noodzakelijk om een koppeling met digitale middelen op te zetten tussen de Android- en de webapplicatie die verifieert dat de auteur eigenaar is van beide applicaties.
Volg de officiële gids om een digitale activalink in te stellen. Gebruik voor de linkrelatie "delegate_permission/common.use_as_origin"`, wat aangeeft dat beide apps tot dezelfde oorsprong behoren zodra de link is geverifieerd.
Maak een aangepaste tabbladintentie met extra kopteksten
Er zijn meerdere manieren om een aangepaste tabbladen-intentie te maken. U kunt de builder gebruiken die beschikbaar is in AndroidX door de bibliotheek toe te voegen aan de build-afhankelijkheden:
MULTI_LINE_CODE_PLACEHOLDER_1
Bouw de intentie op en voeg extra headers toe:
MULTI_LINE_CODE_PLACEHOLDER_2
Stel een aangepaste tabbladverbinding in om de Asset-link te valideren
Voor het opzetten van een CustomTabsSession tussen de app en het Chrome-tabblad wordt een Custom Tabs-verbinding gebruikt. We hebben de sessie nodig om te verifiëren dat de app en de webapp tot dezelfde oorsprong behoren. De verificatie slaagt alleen als de digitale asset-koppelingen correct zijn ingesteld.
Het wordt aanbevolen om CustomTabsClient.warmup() aan te roepen. Hiermee kan de browsertoepassing vooraf op de achtergrond initialiseren en het openen van de URL versnellen.
MULTI_LINE_CODE_PLACEHOLDER_3
Stel een callback in die de intentie na validatie lanceert
De CustomTabsCallback is doorgegeven aan de sessie. We hebben de onRelationshipValidationResult() ingesteld om de eerder gemaakte CustomTabsIntent te starten zodra de oorsprongsverificatie is geslaagd.
MULTI_LINE_CODE_PLACEHOLDER_4
Bind de serviceverbinding met aangepaste tabbladen
Door de service te binden, wordt de service gestart en wordt uiteindelijk onCustomTabsServiceConnected() van de verbinding aangeroepen. Vergeet niet de service op de juiste manier te ontbinden. Het binden en ontbinden wordt doorgaans gedaan in de levenscyclusmethoden onStart() en 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);
Demo-applicatiecode
Meer informatie over de service voor aangepaste tabbladen vindt u hier . Zie de Android-browser-helper GitHub-repository voor een werkende voorbeeldapp.
Samenvatting
In deze handleiding werd gedemonstreerd hoe u willekeurige headers kunt toevoegen aan CORS-verzoeken op aangepaste tabbladen. Goedgekeurde headers kunnen worden toegevoegd aan elk CORS-verzoek op maat. Niet-goedgekeurde headers worden over het algemeen als onveilig beschouwd in CORS-verzoeken en Chrome filtert deze standaard. Het koppelen ervan is alleen toegestaan voor clients en servers van dezelfde oorsprong, geverifieerd door een digitale asset-link.