Agrega encabezados de solicitud HTTP adicionales

Las solicitudes HTTP contienen encabezados como User-Agent o Content-Type. Además de los encabezados adjuntos navegadores, las aplicaciones de Android pueden agregar encabezados adicionales, como Cookie o Referrer, a través del EXTRA_HEADERS Intent adicional Por motivos de seguridad, Chrome filtra algunos de los encabezados adicionales. según cómo y dónde se lanza un intent.

Las solicitudes de origen cruzado requieren una capa de seguridad adicional, ya que el cliente y el servidor no sean propiedad de la misma parte. En esta guía, se analiza cómo iniciar esas solicitudes a través de Chrome pestañas personalizadas, es decir, intents lanzados desde apps que abren una URL en la pestaña del navegador. Hasta Chrome 83, los desarrolladores podían agregar encabezados al lanzar una pestaña personalizada. A partir de la versión 83, Chrome se comenzaron a filtrar todos, excepto los encabezados de origen cruzado aprobados, ya que los encabezados no aprobados un riesgo de seguridad. A partir de Chrome 86, es posible adjuntar encabezados no aprobados a Solicitudes de origen cruzado, cuando el servidor y el cliente están relacionados mediante un vínculo de recursos digitales En la siguiente tabla, se resume este comportamiento:

Versión de Chrome Encabezados de CORS permitidos
antes de Chrome 83 En la lista de aprobación, no aprobados
De Chrome 83 a Chrome 85 en la lista de aprobación
a partir de Chrome 86 En la lista de aprobación, no en la lista de aprobación, cuando se configura un vínculo de recursos digitales

Tabla 1: Filtrado de encabezados de CORS no aprobados

En este artículo, se muestra cómo configurar una conexión verificada entre el servidor y el cliente, y cómo usarla para enviar encabezados HTTP incluidos en la lista de entidades aprobadas y no aprobadas. Puedes pasar a Agrega encabezados adicionales a los intents de pestaña personalizada para el código.

Información general

Encabezados de las solicitudes de CORS que están en la lista aprobada y no aprobadas

El uso compartido de recursos multiorigen (CORS) permite que una aplicación web de un origen solicite recursos de un origen diferente. La lista de encabezados aprobados por CORS se mantiene en HTML estándar. En la siguiente tabla, se muestran ejemplos de encabezados incluidos en la lista de entidades aprobadas:

Encabezado Descripción
accept-language Promociona idiomas naturales que el cliente comprende.
Idioma del contenido describe el lenguaje destinado al público actual
tipo de contenido indica el tipo de medio del recurso

Tabla 2: Ejemplos de encabezados de CORS incluidos en la lista de aprobación.

Los encabezados incluidos en la lista de aprobación se consideran seguros porque no contienen datos confidenciales información del usuario y es poco probable que provoquen que el servidor realice operaciones potenciales perjudiciales.

En la siguiente tabla, se muestran ejemplos de encabezados no aprobados:

Encabezado Descripción
bearer-token autentica al cliente en un servidor
origin indica el origen de la solicitud
galleta contiene cookies establecidas por el servidor

Tabla 3: Ejemplos de encabezados de CORS no aprobados.

No se recomienda adjuntar encabezados no aprobados a solicitudes de CORS por parte de los servidores y el estándar HTML se supone que las solicitudes de origen cruzado solo contienen encabezados que están en la lista de entidades aprobadas. Enviando encabezados no aprobados de dominios de origen cruzado permitiría a apps maliciosas de terceros crear encabezados que hacen un uso inadecuado de los cookies que Chrome (o algún otro navegador) almacena y adjunta a las solicitudes. Las galletas podrían para autenticar las transacciones maliciosas del servidor que no serían posibles de otro modo.

Adjuntar encabezados de la lista de aprobación de CORS a las solicitudes de pestañas personalizadas

Las pestañas personalizadas son una forma especial de abrir páginas web en una pestaña personalizada del navegador. Pestaña personalizada los intents se pueden crear con CustomTabsIntent.Builder(). También puedes adjuntar encabezados a estos intents mediante un Bundle con la marca 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"));

Siempre se pueden adjuntar encabezados incluidos en la lista de entidades aprobadas a las solicitudes de CORS de las pestañas personalizadas. Sin embargo, los filtros de Chrome encabezados no aprobados de forma predeterminada. Aunque otros navegadores pueden tener un comportamiento diferente, los desarrolladores deberían esperar que los encabezados no aprobados se bloqueen en general.

La forma admitida de incluir encabezados no aprobados en las pestañas personalizadas es primero verificar el una conexión de origen cruzado mediante un vínculo de acceso digital. En la siguiente sección, se muestra cómo configurar estas y lanzar un intent de pestañas personalizadas con los encabezados requeridos.

Cómo agregar encabezados adicionales a los intents de pestaña personalizada

Para permitir que los encabezados no aprobados se pasen a través de intents de pestaña personalizada, es necesario establecer un vínculo de recursos digitales entre la aplicación web y para Android que verifique que el autor es propietaria de ambas aplicaciones.

Sigue la guía oficial para configurar un vínculo de recursos digitales. Para la relación de vínculo, usa “delegate_permission/common.use_as_origin”`, que indica que ambas apps pertenecen al mismo origen una vez que se verifique el vínculo.

Cómo crear un intent de pestaña personalizado con encabezados adicionales

Hay varias formas de crear un intent de pestañas personalizadas. Puedes usar el compilador disponible en androidX. Para ello, agrega la biblioteca a las dependencias de compilación:

MULTI_LINE_CODE_PLACEHOLDER_1

Compila el intent y agrega encabezados adicionales:

MULTI_LINE_CODE_PLACEHOLDER_2

Se usa una conexión de pestañas personalizadas para configurar un elemento CustomTabsSession entre la app y la Pestaña de Chrome. Necesitamos la sesión para verificar que la app y la app web pertenecen al mismo origen. La verificación solo se aprueba si se configuraron correctamente los vínculos de recursos digitales.

Te recomendamos que llames a CustomTabsClient.warmup(). Permite que la aplicación del navegador se inicializa previamente en segundo plano y acelera el proceso de apertura de la URL.

MULTI_LINE_CODE_PLACEHOLDER_3

Configurar una devolución de llamada que inicie el intent después de la validación

Se pasó CustomTabsCallback a la sesión. Configuramos onRelationshipValidationResult() para iniciar el CustomTabsIntent creado anteriormente una vez que se realice correctamente la verificación de origen.

MULTI_LINE_CODE_PLACEHOLDER_4

Vincula la conexión de servicios de pestañas personalizadas

Cuando se vincula el servicio, se inicia el servicio y el onCustomTabsServiceConnected() de la conexión se llamará más adelante. No olvides desvincular el servicio de manera adecuada. Vinculación y desvinculación por lo general, se hace en los métodos de ciclo de vida de la actividad onStart() y 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);

Código de la aplicación de demostración

Puedes obtener más detalles sobre el servicio de pestañas personalizadas aquí. Consulta la android-browser-helper de GitHub para una app de ejemplo en funcionamiento.

Resumen

En esta guía, se demostró cómo agregar encabezados arbitrarios a las solicitudes de CORS de pestañas personalizadas. los encabezados incluidos en la lista de aprobación se pueden adjuntar a cada solicitud de CORS de pestañas personalizadas. Los encabezados no aprobados tienen las siguientes características: generalmente se consideran no seguras en las solicitudes de CORS, y Chrome las filtra de forma predeterminada. Adjuntarlos es solo están permitidos para clientes y servidores del mismo origen, verificados por un vínculo de recursos digitales.