Una limitación reciente de la API de Twitter ha impedido que se muestren algunas de las previsualizaciones de enlaces de Discourse. Este componente de tema permite a Discourse admitir incrustaciones nativas de Twitter sin necesidad de las API de Twitter.
El componente de tema solicita un script de Twitter de platform.twitter.com, por lo que si Twitter quisiera, podría rastrearte en este script y causar problemas de privacidad. Debes sopesar si confiar en esta plataforma social que se está volviendo cada vez más ridícula.
Para usar este componente, debes agregar el enlace de Twitter al rango de permisos de la política de seguridad del sitio en la configuración del sitio y agregar twitter.com y x.com a los dominios de previsualización bloqueados.
Gracias, lo he resuelto. Después de eliminar la clave y el secreto del consumidor de Twitter de la configuración, ahora funciona como se esperaba. Creo que estaba intentando incrustar usando la API por defecto porque no los había eliminado. Gracias de nuevo por hacer esto, sería genial si algo así fuera posible también para Instagram.
Funciona como se anuncia para mí, pero quizás no está tan claro que en la vista previa solo se ve la URL del tweet como un hipervínculo, la incrustación ocurre cuando se envía la respuesta o la publicación.
Ya hemos realizado todas las modificaciones recomendadas anteriormente. Nuestro problema ahora es solo al intentar publicar desde un dispositivo móvil… incrustar un Tweet usando una laptop/computadora de escritorio funciona bien ahora.
A algunas personas les gustan los incrustados y no necesitan la funcionalidad de “inicio de sesión”, por lo que este componente será muy popular y sí, también veo solicitudes para otras plataformas.
Personalmente, me gusta más el estilo de incrustación de Twitter de aspecto natural que el Onebox; si los incrustados de las plataformas más populares conservan el aspecto nativo, los diferencian bien en el flujo de un tema. Verdaderamente un gran trabajo y no puedo evitar pensar por qué no tuvimos esto antes para evitar todas las complejidades de la configuración de la cuenta de desarrollador, pero ahí lo tienes, las necesidades obligan y los valientes y audaces aceptan el desafío.
En otro punto sobre la fragilidad de los embeds como contenido, tras observar el tema de la implosión de Twitter, me hizo pensar de nuevo en una vieja idea que tenía.
Si los embeds pudieran generar un mapa de bits de respaldo de la vista previa del embed como parte de la función de embed, eso protegería contra los resultados de Photobucket y similares.
No tengo idea de cómo se podría codificar, pero imagino que funcionaría en principio de manera similar a la función que captura la imagen de un enlace de imagen publicado y se almacena en la base de datos nativa, mientras que supongo que es más fácil ya que es un archivo ya existente en algún servidor, actuaría como, supongo, lo mismo que una función de captura de pantalla personalizada sobre la marcha, que ocurre cuando un embed se confirma en una publicación de Discourse.
Los sitios que archivan un nivel de su contenido es útil, ya que la red envejece, las cosas desaparecen de vez en cuando.
También voy a sugerir otra característica en esta línea aquí
Esto es importante y se acaba de descubrir, al juntar 2 y 2: si no tenías CSP habilitado antes y usas, por ejemplo, Google Adsense, anularás tus anuncios al activar CSP si usas cifrado (DM) para que el componente de Twitter funcione, ¡ya que hay un posible conflicto!
Me gustaría que me demostraran que estoy equivocado con una súper solución o “lo hiciste mal”
Presumiendo que la integración de Twitter (oneboxing) a través de la API ahora requiere una suscripción de pago a Twitter, ¿este método podría/debería añadirse al núcleo de Discourse? Las grandes comunidades empresariales pueden permitirse las tarifas de Elon, pero están fuera del alcance de las organizaciones sin fines de lucro y las comunidades pequeñas.
La erosión de Twitter es un caso difícil de manejar. Sigue siendo la fuente número 1 para la mayoría de las noticias y eventos, utilizada por medios de comunicación, corporaciones y personas de interés. A pesar de la sacudida de Elon, no hay un competidor o alternativa creíble para la plataforma.
Lamentablemente, este componente no funciona en mi instancia de Discourse. Eliminamos las claves de inicio de sesión de Twitter, pero todavía nada. También habilitamos CSP.
Perder los rich embeds ciertamente no es deseable, y lo estamos discutiendo para ver qué se puede hacer al respecto.
Cuando pegas un enlace de Twitter en el compositor, ¿qué devuelve la pestaña de red de las herramientas de desarrollador de tu navegador?
¿Hay errores en la consola de javascript?
Lo estamos pensando, pero hay dos problemas muy grandes que deben abordarse aquí:
IFRAME significa que permitimos que Twitter rastree a los usuarios. Existen preocupaciones de privacidad.
IFRAME significa que necesitamos luchar contra la guerra de la altura “desconocida”. Si no tenemos altura y solo la obtenemos después de hablar con Twitter, la página salta mucho, lo que puede afectar en gran medida la experiencia de Discourse. Determinar la altura con anticipación es muy difícil.
Absolutamente. Esta solución alternativa del componente temático carga JavaScript desde los servidores de Twitter y, considerando cómo le está yendo a Twitter en general, esto supone un riesgo masivo para la privacidad. Por lo tanto, soy reacio a aplicar este componente temático, al menos por ahora.
Ahora los embeds funcionan, pero la vista previa del compositor todavía muestra el mensaje “Lo sentimos, no podemos generar…”. Cuando se publica, todo se ve bien.
