Inicio de sesión con token

Con el inicio de sesión con token, tu sistema envía al usuario a la plataforma con un token en la dirección. La plataforma valida ese token contra un servicio web externo tuyo y, según la respuesta, deja entrar al usuario o no.

Cómo funciona

1. Tu sistema genera un token para un usuario concreto y lo redirige a esta dirección:

   https://{dominio}/#signin?token={token}

   Donde {dominio} es el dominio de tu plataforma y {token} es el token generado. Por ejemplo, para la plataforma demo y el token abc123: https://demo.teachlr.com/#signin?token=abc123.

2. La plataforma hace una petición GET a la Ruta que configuraste. Incluye las cabeceras que definiste y la cabecera del token con el valor Bearer {token}.

3. Tu servicio web verifica el token y responde. Con la respuesta, la plataforma permite o impide el acceso.

Si quieres que el usuario aterrice en una página concreta después de entrar, agrega el parámetro redirect con la dirección de una vista de la plataforma:

https://demo.teachlr.com/#signin?token=abc123&redirect=dashboard/student/curso-ej

Configurar el complemento

1. Abre Administración, elige Complementos en el bloque Compañía y despliega Inicio de sesión.
2. Abre Token.
3. Completa los campos:

Campo	Qué es
Ruta	Obligatorio. La dirección (endpoint) de tu servicio web, a la que se envía el token con una petición GET.
Cabecera de envío de token	El nombre de la cabecera que lleva el token. Por defecto es Authorization y puedes cambiarlo. Su valor no se edita: siempre es la palabra Bearer seguida del token.
Cabeceras adicionales a enviar	Pares Nombre y Valor que se incluyen en la petición. Pulsa Añadir para agregar cada una.
Permitir el aprovisionamiento	Casilla de la pantalla. [pendiente: describir qué hace]

Si no especificas ninguna cabecera, se envía Content-Type: application/json.

4. Pulsa Guardar cambios. Según el instructivo, el complemento tiene un interruptor para activarlo o desactivarlo y antes de activarlo debes llenar y guardar todos los campos. [pendiente: confirmar la ubicación del interruptor en la pantalla actual]

El formulario también incluye un enlace a las Instrucciones en PDF.

Qué debe responder tu servicio

Respuesta correcta. Un código HTTP 2xx con este cuerpo, que debe incluir el objeto user_data con al menos el external_id:

{
  "message": "OK",
  "user_data": {
    "external_id": "EXID-123456"
  }
}

El external_id es un identificador único por usuario que defines tú. Si el código es 2xx pero el cuerpo no cumple este formato, la plataforma trata la respuesta como fallida.

Datos del usuario (opcionales). Además del external_id, user_data puede traer estos atributos:

Atributo	Corresponde a	Longitud máxima
email	Email válido	255
about	Biografía	500
name	Nombre	100
last_name	Apellido	100
job	Cargo	200
department	Departamento	254
country	País, escrito como aparece en la lista de países del instructivo (español, inglés, francés, portugués y hebreo)	255
city	Ciudad	500
phone	Teléfono	30
identification_number	Número de identidad	30
employee_number	Número de empleado	254
organization_name	Nombre de la organización	60
external_id	ID externo (obligatorio)	254
alternative_id	ID alternativo, del inicio de sesión alternativo	254
course_id	Arreglo con los IDs de los cursos a los que se suscribe al usuario tras entrar	-
group_id	Arreglo con los IDs de los grupos a los que se suscribe al usuario tras entrar	-
update	true o false: si se actualiza la información ya registrada	-

También puedes enviar atributos personalizados. Los nombres y significados de los atributos básicos y personalizados están en la página https://{dominio}/#csv de tu plataforma.

Reglas que conviene conocer

• Si email, employee_number o alternative_id ya pertenecen a otro usuario, ese atributo se ignora.
• Si el usuario no existe, identificado por su external_id, y envías user_data, se registra un usuario nuevo con todos los atributos, sin importar update.
• Si el usuario ya existe, su información solo se actualiza cuando update es true. Si no lo envías, su valor es false.
• Caso especial: si el usuario no existe por external_id y llega un email, la plataforma busca un usuario con ese correo. Si lo encuentra y no tiene external_id, le asocia el recibido. Si ya tiene un external_id distinto, ignora a ese usuario y registra uno nuevo.

Respuesta fallida. Cualquier código que no sea 2xx, por ejemplo 4xx, con este cuerpo:

{
  "message": "Mensaje de error"
}

La plataforma muestra al usuario el texto de message. Para mostrarlo en varios idiomas, agrega un objeto lang con códigos de dos letras: es, en, fr, pt y he.

{
  "message": "Mensaje de error",
  "lang": {
    "es": "Se ha producido un error",
    "en": "An error occurred"
  }
}

Si no envías message, o la respuesta no es un JSON válido, el usuario ve el mensaje por defecto: «Tus credenciales no pudieron ser verificadas. Por favor, contacta al administrador.»

Relacionados

• Métodos de inicio de sesión disponibles
• Inicio de sesión alternativo por servicio web