Series: User Auth

Login Form

Published on Oct 28, 2015

The login form is the gateway to your application. Make sure it works right.

In this episode we create the template for a login form, and give it some toy functionality that we will expand upon in upcoming episodes.


Links

Code

The login form itself:

<h1>Login</h1>

<div class="field">
  <label>User Name</label>
  {{input value=userName}}
</div>
<div class="field">
  <label>Password</label>
  {{input value=password type="password"}}
</div>
<div class="btn btn-primary" {{action 'login'}}>Login</div>

The login action in the controller:

actions: {
  login(){
    let {userName, password} = this.getProperties('userName', 'password');
    this.get("session").login(userName, password).then(()=>{
      this.transitionToPreviousRoute()
    }).catch((reason)=>{
      console.log(`Error: ${reason}`)
    })
  }
},
transitionToPreviousRoute(){
  var previousTransition = this.get('previousTransition');
  if (previousTransition) {
    this.set('previousTransition', null);
    previousTransition.retry();
  } else {
    // Default back to homepage
    this.transitionToRoute('index');
  }
}

Then the login method in the session service. This will be greatly improved upon next week.

login(userName, password){
  return new Promise((resolve, reject)=>{
    if (userName === 'emberscreencasts' && password === 'awesome'){
       //get user from somewhere
       this.set('currentUser', user)
       Cookies.set('userId', user.id)
       resolve()
    } else {
       reject("Username and password did not match")
    }
  })
}

Transcript

Today we’re going to be continuing talking about our session authentication by doing a login screen. So when we go to the Authenticated route, one that’s behind the paywall, we’re given a login screen.

And so, if we put in the correct password, then we’ll be signed in.

But if we put in the wrong password or a user that don’t exist, then we’ll be shown errors.

So how do we get there? Let’s go back to where we ended the last screencast.

And I’ve only changed one thing. It’s that the authenticated routes point you to the login page instead of the users page, and we’ll fill this in with the form during this screencast.

The form will actually be the easiest part of this.

So first we’ll paste in some minimal css so it looks okay,

and then we’ll get working on the html. So we’ll put in fields and labels for our username and password. This is basic html. I’m just going to type really fast here, and then we’ll have the action of login.

This is our form. Notice that when we type in the password it does little dots.

That’s because we had it type=”password”.

And then when we hit in the login button, we want it to do something. We want it to try to log us in. So we have login methods both in our controller and in our session service.

But they’re predicated on just being handed the user and logging them in with no questions asked. And obviously that’s not going to work for us.

So in our controller, first we’re going to do a little bit of cleanup. We’re going to take all of this logic and we’re going to put it in a separate method,

so we can just have it named nicely and it won’t be confusing us, because we’re going to put a lot more logic that has directly to do with the login into this controller.

Okay, now that that’s out of the way, first we’ll recognize that we’re not just going to get a user passed to us. What we’re going to get is a username and a password. Then we’ll be passing those two to the login method on the session. Then we’ll be wanting it to do something different based on how that returns, so we’ll go ahead and assume it’s a promise and act accordingly. Here you can see that if it goes correctly, then we’re transitioning to the previous route like we were before, but if something goes wrong, then we’re logging error into the console,

And now we need to change the session service, the login method, so that it takes the correct parameters and it returns a promise. So first we’ll put in the userName and the password parameters, then we’ll set it to return a promise. So most of what we’re about to do here is horrible and will be fixed in the next episode, so I’m just going to speed through it and go through the important things.

So we have the if statement and it’s going to check if the userName and password match. In the official one this will be going to the server. So if it’s true, then we’re going to set the currentUser and set the cookies like we did before and then we’re going to resolve. And we do still have to get the user, so we’re going to do something once again terrible, and I repeat, we’re going to be doing better next week. The important thing is that it’s a promise and if the things match then it gets resolved. Then, if the things don’t match, then we’re going to reject and we’ll send an error.

We’ll see this in action. We can just type random stuff, and when we hit login it will logout the error Username and password did not match.

But if we put in our user name with the emberscreencasts and then our password of ‘awesome’ and we login, it logs us in.

So tracing our route through the code again, we’re grabbing the username and password, and then we’re calling the login method on session, and it’s going to be a promise, so if that promise resolves, then we’re going to transitionToPreviousRoute, and if it rejects, then we’re going to log the error,

and this is how we set up our promise.

So I hope you’ll join me in the pro-episode where we first show the success and the failure messages using ember.cli.flash, and then we’ll add more granular validations besides just do they match or not.

Then the week after that we’ll talk about the token authentication, the one we’ve all been waiting for, and then how to create a signup form. I hope to see you then.

User Auth

Subscribe to our mailing list