¿Qué expectativa debería tener sobre cuánto tiempo puede permanecer un usuario conectado antes de que se le solicite iniciar sesión nuevamente?
He implementado mis propias funciones de verificación en functions.php, integrándolas con el plugin SSO para WordPress. Mi lógica parece bastante sencilla, pero acabo de notar que un miembro cuyo tarjeta de crédito fue rechazada (lo que eliminó la etiqueta de usuario que mi lógica verifica) pudo acceder a mi foro hoy. Al verificar más a fondo, descubrí que su última sesión fue hace un par de días y, supongo, parece que sigue activa. Su fecha de último inicio de sesión en WordPress también es de hace unos días.
¿Es de esperar que sus credenciales en caché sigan funcionando? De ser así, ¿existe alguna forma de controlar la validez del token y/o responder a un webhook para forzar el cierre de sesión?
Esto se controla mediante la configuración del sitio de Discourse maximum session age. Establece el número de horas durante las cuales los usuarios permanecerán conectados en tu sitio. El valor predeterminado es de 1440 horas (60 días). Podrías probar configurándolo con un valor más bajo. Si lo configuras demasiado bajo, parecerá un error para tus usuarios.
Esto tiene sentido. Puedes cerrar la sesión de los usuarios manualmente yendo a la página de administración de Discourse y haciendo clic en el botón ‘Cerrar sesión’ que verás en la parte superior derecha de la página. Otra opción para controlar esto sería agregar algo de código a tu sitio de WordPress que cierre la sesión de los usuarios de Discourse cuando una membresía expire.
Muy agradecido, Simon. Aunque creo que 60 días es demasiado tiempo para mis escenarios (son miembros que pagan, por lo que esperan que verifiquemos que sigan siendo miembros válidos), coincido en que reducirlo demasiado puede ser molesto.
La última sugerencia (encontrar una forma de cerrar la sesión de Discourse cuando finalice la membresía) es lo que investigaré. Ya había visto la opción de cerrar sesión manualmente, pero busco automatizar todo esto por completo, así que parece el camino correcto.
Hmm… la descripción de la configuración del sitio dice (mi énfasis):
El usuario permanecerá iniciado durante n horas desde la última visita
Si entiendo correctamente, ¿podría permanecer iniciado para siempre si sigue visitando el sitio periódicamente, incluso después de perder sus credenciales de SSO? Por ejemplo, si la configuración estuviera establecida en 72 horas, siempre que continuara visitando el sitio cada día o dos, seguiría iniciando sesión. ¿Interpreto eso correctamente?
Sí, eso es cierto en mi experiencia. No hay un tiempo de espera absoluto que cierre la sesión de alguien de forma obligatoria después de un período fijo.
¿Entonces la implicación de esto es que si alguien cancela mi membresía y quiero asegurarme de que no pueda acceder a mi foro, tendré que desconectarlos a la fuerza (manualmente o mediante una llamada a la API)?
Gracias. Acabo de migrar desde un grupo de Facebook (que requería eliminar manualmente a los miembros cuando cancelaban sus suscripciones), por lo que es lamentable que, con Discourse, aún tenga un proceso manual para asegurar que los miembros que han cancelado no puedan acceder a mi foro. Eso me lleva a una pregunta.
¿Existe algún mecanismo no manual —por creativo que sea— que me permita asegurar que un usuario que ya no tiene una cuenta válida, es decir, que no puede iniciar sesión, sea desconectado forzosamente de Discourse?
Parece lógicamente extraño que el mecanismo de SSO bloquee a los usuarios para que no puedan iniciar sesión (reconociendo que no tienen una cuenta válida), pero si simplemente acceden al foro con regularidad (antes de que expire el tiempo de espera), pueden permanecer en él tanto como quieran hasta que los desconecte manualmente.
Supongo que mi última opción, potencialmente, sería escribir un plugin que llame a la API de Discourse para desconectarlos cuando cancelen.
Estoy abierto a cualquier idea. Como pueden ver, ¡realmente quiero evitar tener que hacer esto manualmente!
Sin embargo, retrocediendo un poco, ¿esto no parece ser un problema? Supongo que podemos debatir la importancia de esto, pero tener una plataforma donde los usuarios puedan seguir acciendo a un foro indefinidamente, incluso cuando ya no tienen una cuenta válida, es algo que no he visto en ningún otro lugar.
Puede que acepte la idea de que es WordPress, y no Discourse, la fuente autorizada aquí. Eso probablemente señala al plugin SSO como el mejor lugar para ubicar cierta lógica.
Estoy curioso por conocer el razonamiento general aquí. Me gustaría pensar que este escenario es válido (forzar el cierre de sesión después de un cierto período de tiempo o basándose en que una cuenta de WordPress se vuelva “inválida”), ¿no?
Solo estoy haciendo lluvia de ideas, ya que me gustaría evitar pasos manuales, pero también quiero evitar escribir código, si puedo
Sí, esto tendrá que ser manejado por WordPress. Creo que tendría sentido que el plugin WP Discourse cierre la sesión de los usuarios en Discourse cuando estos sean eliminados en WordPress, pero no estoy seguro de que eso resuelva tu problema. Mi suposición es que, cuando la membresía de un usuario vence en tu sitio, el usuario no se elimina de tu sitio de WordPress. Para manejar el caso de cerrar la sesión de un usuario en Discourse cuando su membresía vence, probablemente necesitarás agregar algo de código a tu sitio que se conecte a cualquier acción que se active en tu plugin de membresía cuando esta vence.
Gracias de nuevo, @simon. Tus puntos tienen sentido, pero perdóname si sigo un poco más
Parece que hay dos factores en juego aquí: la validez de una cuenta (es decir, si es un miembro activo) y la validez de un token en Discourse.
En cuanto al primero, estoy totalmente de acuerdo en que WordPress debería ser el responsable y, con el tiempo, lo investigaré.
Sin embargo, también está la cuestión de un token activo/válido en el lado de Discourse. Entiendo que esto podría no ser una prioridad alta, pero veo cierta lógica en una opción (probablemente desactivada por defecto) que tenga un período de “inicio de sesión forzado”, es decir, que después de x días el token de inicio de sesión del usuario expire, independientemente de si ha iniciado sesión recientemente.
De nuevo, estoy simplemente haciendo lluvia de ideas, pero veo cierto valor en ofrecer la opción de forzar un cierre de sesión, independientemente de si el usuario tiene una cuenta válida.
Debes realizar una solicitud POST autenticada a la ruta. Podrías configurarlo para cerrar la sesión de los usuarios cuando hagan clic en un enlace, pero tendrás que manejar la solicitud en el servidor.
¡Gracias! ¿Autenticado, eh? Estoy investigando esto y parece que una publicación autenticada desde PHP envía algo así en el encabezado:
'Authorization: OAuth '.$accesstoken;
Hay algunas pistas por ahí que seguiré investigando.
Pero sería genial si alguien tuviera un fragmento de código PHP que funcionara… ¡el ejemplo en la sección de autenticación de https://docs.discourse.org/ me devuelve un error de sintaxis… oh, espera, ¡eso es un comando de Unix!
Dado que estás usando WordPress, podrías intentar hacer la solicitud con la función wp_remote_post. De esa manera, no tendrás que lidiar con las opciones de curl.
Gracias, pero no estoy usando WordPress. Estoy intentando hacerlo en PHP en un gestor de membresías que he desarrollado yo mismo durante la última década.
