==========================
Registro a través de Kiosk
==========================
Después de que un nuevo jugador ha comprado una tarjeta de identificación, pasa
a Kiosk para identificarse por primera vez. El sistema nota que la tarjeta es
nueva y ofrece dos opciones. La primera es asociarla a una cuenta de Jugador
existente. Esto es reposición de tarjeta. La segunda opción es registrar una
nueva cuenta de ``Player``.

El flujo descrito en este documento implica que se escoge la segunda opción: 
registro de una nueva cuenta de ``Player``.

Descripción general
===================

.. image:: /images/kiosk_sign_up_overview.svg
   :align: center

1. Kiosk envía a Offsite la ``card_key`` leía. Este endpoint es el mismo que el
   empleado en el flujo de identificación.
2. El endpoint responde que se trata de una tarjeta que está dada de alta, pero
   que no tiene asociado un ``Player``. El Jugador indica que quiere registrarse
   y proporciona la información correspondiente.
3. Kiosk envía toda la información que compone el registro a Offsite.
4. Offsite responde con la primera autorización de *check in* del usuario.

Flujo
=====
Con una tarjeta nueva se pueden realizar una de dos operaciones: asociarla a una
cuenta existente, o indicarla como primera tarjeta de un nuevo ``Player``. Este
flujo es para este último.

Detección de la tarjeta nueva
-----------------------------

.. image:: /images/kiosk_check_in_redirect_sequence.svg
   :align: center

En este caso, la tarjeta que lee Kiosk ya está dada de alta en el sistema pero
no está asociada a un Jugador. Offsite se lo hace saber con una respuesta con el
estado ``307 Temporary Redirect``. La respuesta debe incluir el ``id`` de la
tarjeta.


Consulta de avatares
--------------------

.. image:: /images/kiosk_avatar_fetching_sequence.svg
   :align: center

Se lleva a cabo como se indica en :ref:`obtener-avatares`.


Registro de un nuevo Jugador
----------------------------

.. _registro-jugador:

Offsite: ``POST /kiosk/players``
********************************

**Autorización:** Kiosk

Una vez con la información de la nueva tarjeta, Kiosk reúne los siguientes datos
que componen el registro.

.. code-block:: yaml

    sign_up:
      nick: ColonelFatso
      email: fatso@example.com
      password: password
      birthday: 1987-04-23
      gender: 0
      avatarId: 152
      idCardKey: '5eRtk123'

La respuesta debe tener el código de estado ``201 Created`` y contiene la
información del jugador y una autenticación de check in. Kiosk usa esto para 
integrar al usuario al flujo de check in.

Validaciones
^^^^^^^^^^^^
- El ``nick`` debe ser único.
- El ``email`` debe ser único.
- La fecha de nacimiento debe estar en el pasado.
- El género debe ser ``0`` para mujer o ``1`` para hombre. 
- El identificador del avatar debe existir.
- El identificador de la tarjeta debe pertener a una tarjeta nueva. Es decir, 
  una tarjeta dada de alta pero que no está asociada a ningún jugador.
- El ``nick`` no debe contener a *guest* (ignorando mayúsculas y
  minúsculas) como subcadena.
- El ``nick`` debe tener longitud entre 4 y 25 caracteres, constar únicamente de
  símbolos alfanuméricos y los símbolos ``-``, ``_``.
- El enlazado de la tarjeta debe hacerse en el país donde fue registrada
  en el sistema.
- La tarjeta no debe estar inhabilitada.

Comprobar disponibilidad de ``nick`` y ``email``
------------------------------------------------
Existen dos pantallas en el flujo en el que Kiosk tiene que corroborar la 
disponibilidad del ``nick`` y del ``email`` respectivamente. Esto se realiza
haciendo una búsqueda a :ref:`obtener-jugadores`.

.. image:: /images/kiosk_get_players_sequence.svg
   :align: center

Entre otros campos, este endpoint puede buscar por ``nick`` o por ``email``.
Kiosk revisa si esta consulta regresa algún resultado. En tal caso, el valor
no está disponible.