Tutorial: Validación en tiempo real del login vía Email o código usando llamadas HTTPS o integraciones Seguir
El sistema de login vía Email o vía código de Easypromos sirve para permitir o denegar el acceso a los usuarios en las promociones gestionadas con Easypromos.
En el caso de la validación vía email, el sistema, hasta ahora, validaba el formato del email y opcionalmente enviaba un email de confirmación a la dirección de correo del usuario, para que éste certificase que era él quien solicitaba acceso a la promoción.
En el caso de la validación vía código ya disponíamos de varias opciones para validar el código introducido por el usuario (expresión regular, set de códigos, algoritmo Luhn).
En esta actualización hemos añadido nuevas opciones de validación por email y vía código que resultarán muy útiles a los administradores de nuestras campañas.
En el caso de la validación vía email, estas nuevas opciones son accesibles desde el selector de "Restricciones de email", tal como se muestra en la siguiente imágen:
En el caso de validación por "Número de cliente" podemos encontrar una nueva opción del selector de validación de códigos, "A través de API externa (Webservice)", tal como se muestra en esta imagen:
Las opciones en los dos tipos de validaciones son:
Pasemos a detallar cada una de las opciones.
1. En la validación de emails
1. 1. Restricción por dominio
Esta restricción permite a los administradores restringir los dominios de los correos electrónicos de los usuarios que desean participar en una promoción. Sólo tendrán acceso aquellos emails que pertenezcan a los dominios listados en la lista de dominios especificados. Esta restricción es especialmente interesante cuando una compañía desea restringir la entrada a una campaña a usuarios que dispongan de un correo corporativo.
A continuación, mostramos el ejemplo de la configuración de la restricción por dominios de email. En este caso sólo permitiriamos emails con el formato xxx@easypromosapp.com o yyy@otraempresa.com
1.2. Restricción por lista cerrada de emails
Esta restricción permite al administrador filtrar el acceso a la promoción solo a los usuarios con el email que aparezca en la lista. Previamente se debe crear un "set de códigos" dentro de Easypromos con la lista detallada de todos los emails que podrán entrar en la promoción.
Este caso es útil cuando tenemos una lista de emails que han participado en un evento y queremos que sólo estas personas entren en una promoción y obtener algún premio, por ejemplo.
La validación de los emails válidos se realiza sin tener en cuenta mayúsculas y minúsculas, por ejemplo si en la lista aceptamos Nombre.Apellido@gmail.com serían válidos los emails nombre.apellido@gmail.com, Nombre.Apellido@gmail.com y también NomBRE.ApELLido@gmail.com y todas las combinaciones de mayúsculas y minúsculas posibles.
1.3. Integración con una lista de Mailchimp
También podemos restringir la entrada a la promoción detectando si el email está subscrito a una lista de correo de Mailchimp. Para ello deberémos introducir la API Key de Mailchimp y posteriormente seleccionar la lista que queremos usar para permitir el acceso a los usuarios.
Esta funcionalidad nos permite, por ejemplo, dejar acceder a los usuarios de nuestra newsletter a la promoción para obtener premios o jugar a juegos exclusivos. La ventaja de esta integración es que el acceso se actualiza en tiempo real con los subscriptores de la lista de Mailchimp, así evitamos problemas de sincronización de datos.
1.4. Integración vía API genérica del cliente HTTPS REST
Esta opción permite validar en tiempo real el email introducido por el usuario contra un webservice programado por el cliente.
Actualmente están soportadas llamadas a URLs vía HTTPS con el verbo GET y esperando una respuesta de tipo JSON.
La URL debe responder con un código 200 si el email tiene acceso a la promoción. Si se recibe cualquier otro código se interpretará que el usuario no tiene acceso a la promoción.
Al ser una comprobación en tiempo real cada vez que el usuario introduce el código se realiza la llamada al webservice. Esta llamada tiene un timeout de 2 segundos. La implementación del webservice, por tanto, debe ser capaz de devolver el código 200 en menos de dos segundos para no perjudicar la experiencia del usuario, en caso contrario la validación fallará.
Cabeceras
La configuración de Cabeceras es especialmente importante ya que permite proteger la url del cliente con tokens privados y evitar que la API sea consultada con posibles ataques de fuerza bruta. Las peticiones a la API se realizan de servidor a servidor, con lo que estos tokens nunca serán visibles desde el navegador del usuario.
URL del Webservice
La URL del servicio debe apuntar al endpoint programado por el cliente. Este endpoint debe aceptar un parámetro {EMAIL} en la propia url o como parámetro GET.
Ejemplos de URLs válidas para comprobar el email:
- https://mypromo.com/validate/{EMAIL} por ejemplo https://mypromo.com/validate/aaa@gmail.com
- https://mypromo.com/{EMAIL}/validate por ejemplo https://mypromo.com/aaa@gmail.com
- https://mypromo.com/validate?email={EMAIL} por ejemplo https://mypromo.com/validate?email=aa@bb.com
Testing
Se puede usar la función de [Realiza un test] para probar distintos emails y ver la respuesta. Para cada email introducido se muestra la respuesta del webservice en la pantalla emergente del test, por ejemplo:
Para poder probar esta función antes de programar la URL definitiva hemos creado dos URLs de prueba, una que responde siempre con un código 200, aceptando el email. Y otra que devuelve un código 404, rechazando cualquier email.
Estas URLs son:
- https://wl.easypromosapp.com/v24/ok/{EMAIL} - Para el caso de todo OK
- https://wl.easypromosapp.com/v24/ko/{EMAIL} - Para el caso de todo ERROR
Si por ejemplo configuramos la URL de siempre error en el Editor de una promoción tal como vemos en esta imagen:
El usuario nunca podrá entrar en la promoción ya que siempre obtendrá un error.
Por supuesto, estas URLs sólo son de prueba. El cliente debe implementar una url pública donde se pueda enviar un email para ser validado. Para evitar un uso malicioso de estas urls se pueden usar los campos header para enviar tokens de seguridad.
2. En la validación de códigos
2.1. Integración vía API genérica del cliente HTTPS REST
Esta opción permite validar en tiempo real el código introducido por el usuario contra un webservice programado por el cliente.
Actualmente están soportadas llamadas a URLs via HTTPS con el verbo GET y esperando una respuesta de tipo JSON.
La url debe responder con un código 200 si el email tiene acceso a la promoción. Si se recibe cualquier otro código se interpretará que el usuario no tiene acceso a la promoción.
Al ser una comprobación en tiempo real cada vez que el usuario introduce el código se realiza la llamada al webservice. Esta llamada tiene un timeout de 2 segundos. La implementación del webservice, por tanto, debe ser capaz de devolver el código 200 en menos de dos segundos para no perjudicar la experiencia del usuario, en caso contrario la validación fallará.
Cabeceras
La configuración de Cabeceras es especialmente importante, ya que permite proteger la URL del cliente con tokens privados y evitar que la API sea consultada con posibles ataques de fuerza bruta. Las peticiones a la API se realizan de servidor a servidor, con lo que estos tokens nunca serán visibles desde el navegador del usuario.
URL del Webservice
La URL del servicio debe apuntar al endpoint programado por el cliente. Este endpoint debe aceptar un parámetro {CUSTOMER_NUMBER} en la propia URL o como parámetro GET.
Ejemplos de URLs válidas para comprobar el email:
- https://mypromo.com/validate/{CUSTOMER_NUMBER} por ejemplo https://mypromo.com/validate/aaa
- https://mypromo.com/{CUSTOMER_NUMBER}/validate por ejemplo https://mypromo.com/aaaa/validate
- https://mypromo.com/validate?code={CUSTOMER_NUMBER} por ejemplo https://mypromo.com/validate?code=aaaa
Testing
Se puede usar la función de [Realiza un test] para probar distintos códigos y ver la respuesta. Para cada código introducido se muestra la respuesta del webservice en la pantalla emergente del test, por ejemplo:
Para poder probar esta función antes de programar la URL definitiva hemos creado dos URLs de prueba, una que responde siempre con un código 200, aceptando el código. Y otra que devuelve un código 404, rechazando cualquier código.
Estas URLs son:
- https://wl.easypromosapp.com/v24/ok/{CUSTOMER_NUMBER} - Para el caso de todo OK
- https://wl.easypromosapp.com/v24/ko/{CUSTOMER_NUMBER} - Para el caso de todo ERROR
Si por ejemplo configuramos la URL de siempre error en el Editor de una promoción tal como vemos en esta imagen:
El usuario nunca podrá entrar en la promoción ya que siempre obtendrá un error.
Por supuesto, estas URLs sólo son de prueba. El cliente debe implementar una URL pública donde se pueda enviar un código para ser validado. Para evitar un uso malicioso de estas URls se pueden usar los campos de Cabecera para enviar tokens de seguridad.
Nota: Estas funcionalidades de restricciones al login vía email y código están disponibles para las versiones Marca Blanca o superior de Easypromos.
Comentarios
0 comentarios
Inicie sesión para dejar un comentario.