That was!! You save my day… Thanks a lot!
Could be wrong, but doesn’t this open up a x-site security vulnerability? See:
2 Me gusta
I don’t know much in these matters, but here is my reasoning:
- “same site cookie” is enabled by default, so it is probably much better this way.
- “same site cookie” can be disabled, so it’s probably not a security hole by itself, rather a weakness that could be exploited in conjunction with others. Disable it at your own risks.
Anyone understands why disabling same site cookie enforcement prevents users from log in within an iframe?
¿Podemos tener, por favor, soporte oficial para Discourse en un iframe?
EDIT: ¡Ups! Lo siento, no me di cuenta de que estaba publicando dos años después.
Es muy poco probable que esto sea compatible alguna vez.
2 Me gusta
Jeff,
Primero: Discourse es increíblemente genial, ¡gracias por crearlo!
Segundo: ¿Está documentado en algún lugar qué problemas específicos se esperarían con Discourse incrustado en un iframe, o qué limitaciones lo afectarían en principio?
¡Gracias!
Hola Adam, hace mucho tiempo, déjame intentar responder aquí.
Usar un <iframe> es muy propenso a errores y haría que Discourse fuera muy difícil de usar y lleno de errores que serían difíciles de rastrear. Además, tiende a “encapsular” Discourse, lo que hace que cosas como desplazarse por temas grandes se rompan. Básicamente, los iframes aíslan muchas de las funciones de Discourse.
Una buena opción si estabas considerando usar un iframe sería agregar un encabezado a tu foro que coincida con el resto de tu sitio/aplicación/portal, incluyendo enlaces de navegación. Cuando un usuario haga clic en el foro, verá una navegación similar, pero estará en una URL diferente alojada en otro lugar. Cuando haga clic en un enlace que no sea del foro en el encabezado, volverá al sitio/aplicación/portal.
Espero que esto ayude.
2 Me gusta
¡Gracias por tu respuesta!
¿Podrías compartir cuáles son los problemas específicos que se esperarían? ¿O las razones concretas por las que el contexto de un iframe causaría problemas graves?
¿Qué significa “ventanear” en este caso?
Esto es lo que haremos para nuestro área principal de discusión, pero resulta problemático para este caso de uso específico. Estamos impartiendo cursos en línea. Cada curso tiene lugar en un área privada y con temática especial de nuestro sitio. El contenido del curso incluye materiales de clase, videos, horarios y un área de discusión. Una vez que los estudiantes han completado el curso, pueden continuar las discusiones que iniciaron con otros participantes de su cohorte. También se les añade a un grupo general de discusión para exalumnos del curso y se les invitará a nuestro foro de discusión público y más amplio.
Para nuestro caso de uso, hay dos problemas con el enfoque sugerido aquí:
-
El tema (encabezado, estilos, barra lateral, etc.) del área del curso en nuestro sitio no es el mismo que queremos usar para nuestro Discourse en general. Para adaptarnos a esto, necesitaríamos poder usar diferentes estilos y contenido de tema por categoría, lo cual no parece posible.
-
La discusión del curso en nuestra implementación actual (no basada en Discourse) incluye estilos, encabezado y un menú de barra lateral. Es un espacio de baja distracción donde los estudiantes pueden centrarse en el contenido del curso y cambiar suavemente entre la discusión, los materiales de clase, los videos, etc. Por lo que he podido determinar, sería difícil modificar Discourse para replicar este tipo de entorno inmersivo. ¡Si no es así, estaré encantado de aprender lo contrario!
Gracias por tu ayuda,
Adam
Eso es posible. El elemento body tendrá una clase que indica la categoría actual, lo que te permite delimitar el tema fácilmente usando selectores anidados en SCSS.
En general, te recomendaría agregar algunos widgets de Discourse al área del curso, como nuestra función soportada de lista de temas en iframe documentada en Incrustar una lista de temas de Discourse en otro sitio. De esta manera, los estudiantes podrán ver una lista de las discusiones más recientes relacionadas con su página del curso actual y estarán a un solo clic de unirse a ellas en otra pestaña del navegador.
3 Me gusta
Hola Falco,
Gracias por tu respuesta y disculpa la demora en contestar.
Lamentablemente, la implementación de nuestros cursos es un poco más compleja de lo que puede manejar un alcance de CSS personalizado sin realizar grandes esfuerzos. Por ejemplo, el menú de encabezado incluye un menú desplegable con los cursos en los que el usuario actual está inscrito. Esto se genera dinámicamente desde la base de datos de WordPress, en función del usuario conectado, por lo que sería difícil replicarlo en Discourse.
El menú de la barra lateral en el área de cursos incluye enlaces a varios tipos de contenido del curso, específicos de un curso en particular. Si entiendo correctamente, para que lo que describes funcione, todo este contenido, para todos los cursos, tendría que estar codificado directamente en el tema y luego mostrarse u ocultarse mediante CSS según la clase del cuerpo. ¿Es eso correcto?
Un enfoque que podría funcionar sería utilizar algún JavaScript del lado del cliente en Discourse que obtenga contenido de nuestra API y lo muestre. ¿Es posible agregar scripts personalizados que realicen XmlHttpRequests a otros servidores? ¿Ves alguna razón por la que esto no sería posible?
Sigo esperando una respuesta a esta pregunta.
¡Gracias!
Sí, eso es posible. Solo ten cuidado de no hacer que esas solicitudes bloqueen la renderización de la página.
2 Me gusta