Añadiendo usuarios

6

Porcentaje completado

En este capítulo:

  • Conoceremos cómo funcionan las cuentas de usuario en Meteor.
  • Añadiremos toda la autenticación necesaria para Microscope.
  • Usaremos el paquete accounts-ui para obtener una interfaz de usuario de forma instantánea.
  • Hasta el momento, hemos logrado crear y mostrar algunos datos estáticos y conectarlo todo en un prototipo simple.

    Incluso hemos visto cómo nuestra interfaz de usuario es sensible a los cambios en los datos, y que los cambios aparecen inmediatamente cuando se insertan o cambian los datos. Aún así, nuestro sitio está limitado por el hecho de que no podemos introducir datos. De hecho, ¡ni siquiera tenemos usuarios todavía!

    Veamos cómo arreglamos esto.

    Cuentas de usuario de forma sencilla

    En la mayoría de los frameworks web, agregar cuentas de usuario es un problema familiar. Hay que hacerlo en casi todos los proyectos, pero nunca resulta tan fácil como quisiéramos. Y si además hay que tratar con OAuth u otros esquemas de autenticación de terceros, las cosas tienden a ponerse feas rápidamente.

    Por suerte, Meteor nos ampara. Gracias a la forma en la que los paquetes Meteor pueden contribuir al código del servidor (JavaScript) y al del cliente (JavaScript, HTML y CSS), podemos obtener un sistema de cuentas casi sin esfuerzo.

    Podríamos usar el paquete para cuentas de usuario (meteor add accounts-ui), pero como hemos construido toda nuestra aplicación con Bootstrap, vamos a utilizar ian:accounts-ui-bootstrap-3 (la única diferencia es el estilo). En la línea de comandos, tecleamos:

    meteor add ian:accounts-ui-bootstrap-3
    meteor add accounts-password
    
    Terminal

    Estos dos comandos hacen accesibles las plantillas para cuentas de forma que podemos incluirlas en nuestro sitio usando el ayudante {{> loginButtons}}. Un consejo muy útil: se puede controlar en qué lado aparece el desplegable de inicio de sesión con el atributo align (por ejemplo: {{> loginButtons align="right"}}).

    Vamos a añadir los botones a nuestra cabecera. Y puesto que la cabecera está empezando a crecer, vamos a darle más espacio en su propia plantilla (la pondremos en el directorio client/templates/includes/). Estamos utilizando código y clases como se indica en Bootstrap para que todo se vea mejor:

    <template name="layout">
      <div class="container">
        {{> header}}
        <div id="main">
          {{> yield}}
        </div>
      </div>
    </template>
    
    client/templates/application/layout.html
    <template name="header">
      <nav class="navbar navbar-default" role="navigation">
        <div class="navbar-header">
          <button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#navigation">
            <span class="sr-only">Toggle navigation</span>
            <span class="icon-bar"></span>
            <span class="icon-bar"></span>
            <span class="icon-bar"></span>
          </button>
          <a class="navbar-brand" href="{{pathFor 'postsList'}}">Microscope</a>
        </div>
        <div class="collapse navbar-collapse" id="navigation">
          <ul class="nav navbar-nav navbar-right">
            {{> loginButtons}}
          </ul>
        </div>
      </nav>
    </template>
    
    client/templates/includes/header.html

    Ahora ya podemos ver los botones de acceso en la esquina superior derecha.

    Interfaz de usuario de inicio de sesión en Meteor
    Interfaz de usuario de inicio de sesión en Meteor

    Podemos usarlos para iniciar sesión, solicitar un cambio de contraseña, y todo lo que se necesita para gestionar cuentas basadas ​​en contraseñas.

    Para decirle a nuestro sistema de cuentas que queremos que los usuarios accedan al sistema a través de solo un nombre de usuario, simplemente añadimos un bloque de configuración en un nuevo archivo config.js dentro de client/helpers/

    Accounts.ui.config({
      passwordSignupFields: 'USERNAME_ONLY'
    });
    
    client/helpers/config.js

    Commit 6-1

    Añadidas cuentas de usuario y una plantilla en la cabecera

    Creando nuestro primer usuario

    Adelante, regístrate para obtener una cuenta: el botón “Sign In” cambiará para mostrar el nombre de usuario. Esto confirma que has creado una cuenta. Pero, ¿de dónde vienen los datos de la cuenta?

    Cuando añadimos el paquete accounts, Meteor crea una nueva colección, que se puede acceder desde Meteor.users. Para verlo, abre la consola del navegador y escribe:

     Meteor.users.findOne();
    
    Consola del navegador

    La consola devuelve un objeto que representa el usuario. Si lo inspeccionamos un poco, veremos que contiene nuestro nombre de usuario, así como un identificador único _id. También se puede obtener el usuario que ha iniciado sesión con Meteor.user().

    Ahora, nos registramos con otro usuario y ejecutamos lo siguiente en la consola del navegador:

     Meteor.users.find().count();
    1
    
    Consola del navegador

    La consola devuelve 1. ¿No debería haber 2? ¿Se ha borrado el primero? Si intentas acceder con ese usuario, verás que no es así.

    Vamos a mirar en la base de datos del servidor (meteor mongo en la terminal):

    > db.users.count()
    2
    
    Consola de Mongo

    Definitivamente hay 2, pero, ¿porqué sólo se ve uno en el navegador?

    ¡Una publicación misteriosa!

    Si pensamos de nuevo en el capítulo 4, recordarás que deshabilitamos la auto-publicación autopublish, dejamos de enviar todos los datos procedentes del servidor a las colecciones locales de cada cliente conectado. Tuvimos que crear parejas de publicaciones y suscripciones para intercambiar datos.

    Sin embargo, no hemos creado ninguna clase de publicación para usuarios. Así que ¿cómo es que podemos ver esos datos?

    La respuesta es que el paquete accounts, autopublica los datos básicos de la cuenta del usuario actual, de otra forma, el usuario no podría acceder nunca al sitio.

    El hecho de que el paquete accounts sólo publica el usuario actual explica porqué un usuario no puede ver los detalles de la cuenta de los otros usuarios.

    Así que solo se publica un objeto de usuario por usuario conectado (y ninguno cuando no está autenticado).

    Es más, los documentos en el navegador no parecen contener los mismos campos que en el servidor. En Mongo, un usuario tiene un montón de datos. Para verlo, vuelve a la terminal de Mongo y escribe:

    > db.users.find()
    {
      "_id": "H5kKyxtbkLhmPgtqs",
      "createdAt": ISODate("2015-02-10T08:26:48.196Z"),
      "profile": {},
      "services": {
        "password": {
          "bcrypt": "$2a$10$yGPywo3/53IHsdffdwe766roZviT03YBGltJ0UG"
        },
        "resume": {
          "loginTokens": [{
            "when": ISODate("2015-02-10T08:26:48.203Z"),
            "hashedToken": "npxGH7Rmkuxcv098wzz+qR0/jHl0EAGWr0D9ZpOw="
          }]
        }
      },
      "username": "sacha"
    }
    
    Consola de Mongo

    Por otro lado, en el navegador el objeto de usuario tiene muchos menos campos, como se puede ver escribiendo el comando equivalente:

     Meteor.users.findOne();
    Object {_id: "kYdBd9hr3fWPGPcii", username: "tmeasday"}
    
    Consola del navegador

    Este ejemplo nos muestra como una colección local puede ser un subconjunto seguro de la base de datos real. El usuario conectado solo ve lo necesario para poder hacer el trabajo (en este caso, el nombre de usuario). Este es un patrón que debemos aprender porque nos será muy útil más adelante.

    Eso no significa que no podamos hacer públicos más datos de usuario. Si lo necesitamos, podemos consultar la documentación de Meteor para ver cómo se hace.