browser - useragent - user agent list 2018
¿La detección/detección de agente de usuario del lado del servidor es mala? (3)
Creo que depende de cuál sea tu motivación. Por ejemplo, en el sector web móvil, lo que intenta hacer es proporcionar al usuario algo que parezca sensato en su plataforma. ¿Por qué preocuparse por qué usuario-agente está informando el usuario, cuando es exclusivamente para su propio beneficio? Si se esfuerzan por engañarte con un agente de usuario diferente, entonces son la única persona que sufre. El principal problema, por supuesto, son los falsos positivos; no es del todo confiable.
Sigo el argumento de que no deberías confiar en él como tal, pero los desarrolladores móviles están siendo atacados por afirmaciones generales genéricas como esta. Sí, hay buenas alternativas, pero en todos los navegadores que pueda imaginar, esta información puede ser útil en algún momento dado que la certeza comienza a degradarse.
Lo que ciertamente no hace con ningún encabezado de texto plano es usarlo para facilitar el control de acceso.
La detección del agente de usuario se considera mala cuando hay mejores alternativas, pero ciertamente no hay daño al incluirla en un proceso de detección que se degrada graciosamente con certeza.
El problema que tengo con todo el proceso es que estamos atrapados en proporcionar algo sensato al usuario, pero nunca parecemos pensar que es aceptable preguntar cuando no está seguro. Si no está seguro acerca del usuario-agente, ¿por qué no preguntar una vez y almacenar? Puede usar el agente de usuario como una guía.
Así que para concluir mis pensamientos, esencialmente el encabezado usuario-agente no es confiable, por lo que es malo confiar en él. Esto no significa que no pueda extraer un grado de información valiosa de ella donde las opciones más confiables lo dejen en un estado incierto. En general, es incorrecto concluir que es malo. Es simplemente lo que haces con esta información lo que hace que sea malo o no.
Actualizar
Después de ver sus actualizaciones a la pregunta, tengo los siguientes comentarios para contribuir. ¿Quiero husmear solicitudes de imágenes y proporcionar al cliente una imagen basada en agente de usuario?
Si esta es la única variable, entonces tal vez podría funcionar, pero rara vez sucede que lo único que varía son las imágenes. No quiero detectar por solicitud porque quiero servirle al cliente una solución coherente . Esto significa que les proporcioné una página que hace que soliciten los recursos correctos. Esta página produce una única solución coherente para todos los recursos integrados. Todas las variaciones en este documento trabajan juntas para una vista particular.
Respeto que la posibilidad de que el string de agente de usuario cambie la vista media es tan delgada que no parece que valga la pena preocuparse. Sin embargo, la adopción de este principio también reduce la cantidad de veces que necesita realizar la detección del navegador / plataforma, lo cual solo puede ser beneficioso. Esto le permite cambiar las vistas en el cliente mucho más fácilmente. Si el cliente dice que en realidad tienes la vista equivocada, soy una tableta, no un teléfono, ¿cómo vas a corregir eso? Usted le brinda al usuario una mejor página, de lo contrario tendrá que simular encabezados para sus solicitudes de imágenes ... idea terrible. No utilice la cadena de agente de usuario para servir recursos genéricos como imágenes .
Posibles mejoras
La identificación de plataforma es un área muy activa de desarrollos modernos en la web. A medida que la informática se hace más omnipresente y las plataformas varían mucho más ampliamente, aumenta nuestra necesidad de comprender las plataformas a las que prestamos servicios. Creo que la solución general a este problema en las condiciones actuales va a recaer en la toma de huellas digitales y el análisis estadístico.
Considere esta aplicación - akinator.com - Observe cómo el análisis estadístico de un gran conjunto de datos dispersos es extremadamente preciso. En un entorno limitado (el conjunto de configuraciones del navegador), puede imaginarse que podríamos hacerle algunas preguntas al navegador del cliente. Luego realizamos un análisis estadístico de la respuesta en algún espacio de características n-dimensional. Usar el agente de usuario como una dimensión de este espacio será útil y autolimitante, según los resultados que encuentre. Si es en gran parte inexacta, verá una gran dispersión, y la cantidad de valor que se deriva de ella será autolimitada.
Por supuesto, su capacidad para obtener cualquier valor de este modelo estadístico requiere que pueda obtener algunas verdades verificadas. Esto podría ser, por ejemplo, ejecutando un conjunto de pruebas de JavaScript para detectar las capacidades del lado del cliente js, o de hecho, en la incertidumbre, puede pedirle al usuario que le diga cuál es su plataforma.
Para seguir leyendo, te recomendaría este artículo de Mozilla
https://developer.mozilla.org/en/Browser_detection_using_the_user_agent
Hoy, buscar estas cadenas es la única forma de saber que el dispositivo se ejecuta en un dispositivo móvil (o una tableta) antes de servir el HTML.
Se sabe que la detección del agente de usuario del lado del cliente es mala y desaconseja a favor de la detección de características . Sin embargo, ¿también es malo reaccionar de manera diferente según el campo del agente de usuario entrante en una solicitud HTTP ?
Un ejemplo sería enviar imágenes más pequeñas o más grandes según si el agente de usuario entrante es móvil o de escritorio.
En el escenario de "navegador estándar" no es malo PERO no es confiable, ya que muchos navegadores ofrecen al usuario alguna opción de configuración / complemento / lo que sea para modificar el agente de usuario.
En tal situación, implementaría algo similar a Facebook: detectan en base a UA (y posiblemente otras cosas también conocidas como "análisis de huellas dactilares") si redirigen a una versión de mobbile (es decir, http://m.facebook.com/ . .) o no (es decir, http://www.facebook.com ...). Al mismo tiempo, ofrecen un URL param m2w que anula este mecanismo de redireccionamiento.
Dependiendo del proveedor de telefonía móvil, puede suceder que tengan algún proxy / caché con reconocimiento de contenido que escale / recomprime imágenes sobre la marcha y aparezca en su extremo como un borwser "normal" ...
Pensando en escenarios fuera del navegador ... por ejemplo, si está sirviendo algún protocolo específico (como WebDAV) esta podría ser la única opción para tener algún tipo de comportamiento "específico de la plataforma" (por ejemplo, la diferencia entre OS X y Windows) .
Depende. Usar el agente de usuario como la única señal para ramificar la lógica de su código de nivel de servidor es dudoso en el mejor de los casos e inseguro en el peor, pero funciona para definir las capacidades memorizadas de clases particulares de navegador y servir contenido para satisfacer sus necesidades cuando el vainilla agente se suministra.
El escenario que ha esbozado es una ilustración perfecta de esto. Intentar detectar navegadores móviles y reducir el tamaño del contenido que les envía a nivel de servidor es totalmente apropiado , porque está tratando de adaptar la experiencia del usuario para que se ajuste mejor a sus necesidades (por ejemplo, proporcionando imágenes más pequeñas y mejor flujo de contenido para adaptarse) dentro de las limitaciones de una pantalla más pequeña) al equilibrarlas con las necesidades de su servidor (enviando imágenes más pequeñas, generando así menos carga y menos ancho de banda sobre la línea). Esta estrategia solo necesita un refinamiento.
Hay algunos principios de diseño que siempre debe seguir aquí para asegurarse de que los usuarios no consideren dudosa la práctica de la detección de agente de usuario:
Siempre proporcione la capacidad de ver la versión completa de su sitio y planear su perfil de carga en consecuencia. De lo contrario, las personas intentarán eludir esto cambiando a su agente.
Siempre defina claramente las modificaciones del contenido de su sitio cuando cree una vista modal. Esto borrará cualquier FUD rodee los cambios que usted puede o no haber realizado.
Siempre proporcione rutas a las versiones alternativas de su sitio. Por ejemplo, use algo como
http://mobile.example.orgpara migrar personas a la versión móvil, asumiendo el nivel de diseño que cuando se solicita esta ruta, la audiencia lo solicita explícitamente .Recompense a los usuarios por proporcionarle las credenciales de agente correctas, ofreciéndoles una mejor experiencia en términos de contenido y rendimiento. Los usuarios estarán más contentos cuando haya anticipado sus necesidades y les haya dado un rendimiento más ágil en la versión del sitio que están navegando.
Evite el abuso y los patrones de redirección manual. Por ejemplo, no los bloquees con un gran anuncio flotante de horking para tu aplicación móvil cuando detectes que están ejecutando iOS. (Es cierto que este es un motivo favorito mío).
Nunca restrinja el acceso a las áreas del sitio a través de un agente de usuario (optando por advertir severamente a los usuarios sobre lo que no funcionará si se descarrilan y redactando su política de soporte al respecto). Por ejemplo, muchos de nosotros recordamos con cariño cambiar nuestros agentes por sitios "que funcionen mejor en Internet Explorer", impidiendo el uso de todos los demás navegadores. No debe convertirse en un ejemplo más de esta mala práctica si puede evitarse.
En resumen: proporcionar el agente de usuario correcto es una decisión del usuario. Puede usar esto para definir una experiencia predeterminada para los usuarios que elijan ejecutar sus clientes simples o que no conozcan mejor. El objetivo aquí es recompensar a los usuarios que no proporcionen un agente de usuario falso, dándoles las opciones que necesitan y la experiencia que desean mientras equilibran sus necesidades con las suyas. Cualquier cosa más allá de eso hará que se nieguen, y como tal, debería considerarse extremadamente dudoso.
Ciertamente puede intentar detectar el navegador por otros medios , pero este es aún un área de investigación abierta. Las capacidades del navegador y las huellas dactilares cambian a medida que compiten en las funciones, y tratar de ponerse al día para optimizar el rendimiento a menudo es, en la actualidad, intratable.
Estoy de acuerdo con esta respuesta sobre el uso del análisis estadístico, así que no me malinterpreten aquí. Pero, como alguien que trabaja activamente en esta área, puedo decirte que no hay una solución mágica que te dé una certeza de clasificación perfecta. La heurística, sin embargo, puede y le ayudará a balancear la carga de manera más efectiva, y con ese fin, las estrategias de interrogatorio del navegador pueden utilizarlo una vez que haya definido claramente una tasa aceptable de error.