Detección de agente de usuario del lado del cliente is known to be bad y discouraged in favor of feature detection. Sin embargo, ¿también es malo reaccionar de manera diferente según el user agent field in a HTTP request entrante?¿La detección/detección de agente de usuario del lado del servidor es mala?
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.
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.
que siguen el argumento de que no se debe confiar en él como tal, pero los desarrolladores móviles están bajo el ataque de amplias declaraciones genéricas como este. 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 desde luego no siempre lo hace con cualquier encabezado de texto plano es usarlo para facilitar el control de acceso.
detección de agentesusuario se considera malo cuando hay alternativas mejores, pero sin duda hay ningún daño en su inclusión en un proceso de detección que se degrada con gracia en certeza.
El problema que tengo con todo el proceso es que estamos atrapados en proporcionar al usuario algo sensato, 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 de usuario-agente no es confiable, por lo que es malo para 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.
Después de ver sus cambios a la pregunta, tengo los siguientes comentarios a contribuir. ¿Quiero estar oliendo las solicitudes de imágenes y proporcionando al cliente una imagen basada en el 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 deseo detectar por solicitud porque Quiero servir 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 la cadena 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.
identificación plataforma es un área muy activa de los 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 escasos es molestamente 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 la lectura adicional Yo te remito a este artículo por Mozilla
https://developer.mozilla.org/en/Browser_detection_using_the_user_agent
Hoy en día, en busca de estas cadenas son la única manera de saber que el dispositivo se ejecuta en un dispositivo móvil (o tableta) antes de servir el HTML .
En realidad, al leer su enfoque estadístico (por cierto, es muy común y realizable), me doy cuenta de que la estrategia más correcta es un conjunto de pruebas exhaustivo: para cada versión del navegador, someterlo a la gama completa de pruebas de estándares y use esto para construir una firma suficiente para probar. A partir de ese conjunto de firmas, construya un árbol de búsqueda para bifurcar y minimice el número de detecciones por cliente. Esto requiere que los usuarios habiliten todas sus capacidades (permitiendo, por ejemplo, que Javascript se ejecute), pero un simple aviso para hacerlo sería más que suficiente. – MrGomez
En cuanto a su sugerencia de hacerle al usuario, no creo que esto sea general. La superposición entre los usuarios que han modificado su agente de usuario y los que se encuentran _explícitamente_ en la solicitud directa es lo suficientemente alta como para descartar dicho sistema para su consideración. Aún así, en un sentido abstracto, vale la pena considerarlo en los casos donde no se puede determinar el agente de usuario, por ejemplo, cuando hay una puerta de enlace proxy entre el usuario y el contenido de la página solicitada. Entonces, esto es factible, pero en una capacidad más limitada, creo. – MrGomez
Mis preocupaciones con respecto al enfoque estadístico se extienden más allá de las consideraciones habituales para un mecanismo de detección de usuario-agente. Supongamos que tengo un conjunto de pruebas exhaustivo pero costoso que me gustaría usar para identificar un conjunto de polyfills necesarios del lado del cliente, por ejemplo. Para ejecutar este conjunto en el lado del cliente es un gasto a costo del usuario. El enfoque estadístico, suponiendo que es preciso tener una huella dactilar pequeña de la información fácilmente disponible (que incluye la cadena usuario-agente), puede reducir significativamente el tiempo de detección. –
En el escenario "estándar en el navegador" es no está mal pero es no fiable ya que muchos de los navegadores ofrecen al usuario alguna opción de configuración/plugin/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 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 operador de telefonía móvil que incluso podría ocurrir que tienen alguna basada en el contenido de proxy/cache, que hace escala/volver a comprimir imágenes en la marcha y aparece en su extremo como un borwser "normal" ...
Pensando en escenarios fuera del navegador ... por ejemplo, si usted está sirviendo algún protocolo específico (como WebDAV) esta puede 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).
La redirección a una versión móvil o tener un sitio web móvil separado es un anti patrón conocido y un mal ejemplo;). – Raynos
@Raynos No estoy totalmente de acuerdo, pero la única opción que queda es detectar la detección del lado del cliente (NO del usuario-ganet, pero basada en javascript) e informar al servidor qué capacidades se han encontrado ... – Yahia
La opción real para dispositivos móviles son consultas de medios, mejoras progresivas y diseño receptivo. – Raynos
Depende. Usar el user agent como ú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 contenido que les envía a nivel de servidor es completamente apropiado, porque está tratando de adaptar la experiencia del usuario para satisfacer mejor sus necesidades (por ejemplo, proporcionando imágenes más pequeñas y mejor flujo de contenido) para ajustarse a las limitaciones de una pantalla más pequeña) al tiempo que las equilibra 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 debe siempre siguen aquí para asegurarse de que su práctica de la detección de agentes de usuario no se ve como dudosa por sus usuarios:
siempre ofrecen la posibilidad de ver la versión completa de su sitio y planifique su perfil de carga en consecuencia. De lo contrario, va a que las personas intenten evitar esto al cambiar su agente.
Siempre defina claramente las modificaciones del contenido de su sitio cuando cree una vista modal. Esto borrará cualquier FUD que rodee los cambios que usted puede o no haber realizado.
Always proporcionan rutas a las versiones alternativas de su sitio. Por ejemplo, use algo como http://mobile.example.org para migrar personas a la versión móvil, asumiendo el nivel de diseño que cuando se solicita esta ruta, ha sido explícitamente solicitada por su audiencia.
Recomienda a los usuarios proporcionarles 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 abuso y 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, esta es una manía mía.)
Nunca restringir el acceso a las áreas del sitio sobre una base de agente de usuario (optando en su lugar para advertir a los usuarios con severidad sobre lo que no funcionará si se van fuera de la rails y redactando su política de apoyo 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 por parte del usuario. Puede usar esto para definir una experiencia predeterminada para los usuarios que elijan ejecutar sus clientes simple o aquellos 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 bloqueen, y como tal, se debe considerar extremadamente dudoso.
Sin duda, puede tratar de detectar el navegador by other means, pero esto todavía es 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 this answer en 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.
No creo que sea tan ** malo ** como ** no fiable ** – Leigh
si piensas que es por eso que ves "Mozilla" en cada cadena de UA. Para responder a su pregunta, creo que debería ofrecer opciones, como lo hacen los sitios en la actualidad: redireccionan a los usuarios de dispositivos móviles pero aún así los ofrecen para ver el sitio "normal". – BiAiB
no consideren solo useragent. Análisis de huellas dactilares del navegador, como google et al do – jcolebrand