In a recent app I have written in Ember, I found that the need to display flash messages came up. This has always been given to me for free with Rails, so I didn’t really think of it not being just as easy to integrate using Ember. I was wrong.. well, sort of wrong.

On searching the web for ‘ember flash’, I found a nice little library at https://github.com/cheapRoc/ember-flash by cheapRoc. After some minor tweaking and customization, I was able to get it working in my app.

In this post, I want to share how easy it is to integrate and offer a little explanation as to how it works.

Instead of creating four different files (controller, message, queue and view), I found that placing all of the same file made sense. I created the file flash.js:

A FlashMessage is an Ember object (lines 1-13) which contains the message text and type of message (notice, warning, error). These messages are added into the FlashQueue, which is an array proxy, via the pushFlash function (lines 75-59). There is an observer (lines 83-85) which triggers the function contentChanged whenever a message is added to the queue. When the contentChanged function is called, it places the flash message into the FlashController’s content (lines 68-74). There is an observer watching the content of the controller (lines 55-64) which displays the FlashView for a short period of time, then hides it (lines 58-59). Once hidden, clearContent is called which hides the view and removes the message from the queue (lines 46-53).

On lines 27-43 above, there are animations set up for when the view is to be shown and hidden. These can be modified to anything. What happens in this code is the view will slide down and fade into view. The reverse happens when it is hidden.

Here is the CSS that I am using:

First, you must include the JavaScript and CSS above in your app.

Second, add the view into your template (e.g. application.handlebars)

Application

Finally, trigger messages to be shown with the pushFlash function:

JS Bin

If you have not yet gone through Part 1, I recommend you do. You can check out the code up to this point with the following:

I have created Ember applications using a variety of shortcuts (Yeoman, ember-rails) but have found that Ember Tools is by far the best option available. It allows me to skip the Asset Pipeline completely and work directly in my public folder.

To get started, install Ember Tools using npm.

Once this is installed, you will be able to use the console command ember. Try it out:

Excellent. Now create our Ember app in our public directory with the following command:

With that simple command we now have a nearly functional Ember application. Let’s move the generated index.html file into the public folder and modify it a tiny bit.

Note that the only thing that changed in this file is the path to the application.js file. Go ahead and start up your Rails application and visit http://localhost:3000.

You shouldn’t see anything come up and will likely see an error in the server logs. This is because the page is trying to load application.js when it does not exist. To create the file, run (in another terminal tab within the same root directory):

This created three files: templates.js, index.js and application.js. The two former are used temporarily to create the latter. Now refresh your browser and you should see the starter app:

Running ember build can get very tedious, so let’s create a script which will monitor the file structure and run the command when needed. You will need to have fsmonitor installed if you don’t already:

Create the file bin/ember_build:

Now in a separate tab, make the file executable and run it:

Now whenever we change our Ember app, the code will re-compile.

Ember Tools comes with generators, which I LOVE! Let’s create some files using the generators and fill out our layout page.

Start by creating the route, handlebars template and object controller for users/new. This will be where we register.

Now create the route, handlebars template and object controller for sessions/new. This will be where we login.

Finally, create a page which is TOP SECRET and will require authentication to access. Let’s use an array controller so we can list the users.

Update the application handlebars template to show links to the different pages.

Before these links will work we need to add the routes to the config/routes.js file:

Refresh the browser and you should see something like this:

Add some style with twitter bootstrap by adding the CSS link in your index.html page:

Refresh. You can click on the links as well and you should see the correct pages load.

At the moment, Ember Tools does not provide the latest version of Ember Data, so we will need to add this manually. Save the following file to the path public/javascripts/vendor:

Now update a your main application config file to make sure we are using the latest:

On the blog post found at * http://log.simplabs.com/post/53016599611/authentication-in-ember-js , Marco Otte-Witte (@simplabs) created a simple AuthManager which stores and handles authentication. It is very elegant and once I found this post, I got very excited. I made some minor tweaks to the code, but it is still largely intact.

Create a file in your public/javascripts/config folder called auth_manager.js:

For this to work, we will need to add include jquery.cookies into our app. Download https://raw.githubusercontent.com/carhartl/jquery-cookie/master/src/jquery.cookie.js into the folder public/javascripts/vendor and update the app.js file:

Now create the application router and add the AuthManager to the App in the init function. The reason it goes here is because it’s the first thing that gets run after all the code has been loaded.

Let’s create the parts of our app which will allow a user to register. We want to start off by creating a user model which uses Ember Data:

While we’re here, let’s also create the model for api_key:

For us to use Ember Data, we need to enable it. By default with Ember Tools, the localstorage adapter is enabled by default. Let’s remove that and set the adapter to the REST adapter. Open up config/store.js and make the following changes:

Open up our route for new users and set the model to be a new User record:

Modify the users/new controller with the following:

Now let’s update the handlebars template to show the registration form:

Register

Refresh your browser and fill out the registration form and hit submit. You should be logged in and redirected to the index page.

In your JavaScript console, you can view the currently logged in user with the following:

We’re doing great. We now have created an account. However, the UI hasn’t changed. We want to be told that we are logged in and be given the option to log out.

Let’s create an application controller with some computed properties which we will use in the template:

Now modify the application handlebars template to show the menu based on whether the user is authenticated or not:

Now when we reload the browser it will show our email address when we are logged in with a link to log out. Try it out.

We have an action set up in our application template to log out, but we don’t have an event to handle it yet. Let’s put this in the application route.

Refresh your browser and click ‘Logout’. Works? YAY!!!

Let’s start by updating our the session/new route to assign an Ember Object as the controller’s model:

Now update the sessions/new controller to perform the login:

Finally, update the handlebars template to show the login form:

Login

Refresh your browser and log in. On success, you should be redirected to the index page and the nav bar should indicate you are logged in.

Authentication with Ember is difficult. I have spent a couple of weeks trying out different approaches and failing time and again. With the help of Ryan Florence and Brad Humphrey, I have finally been able to understand how it should work and also have built a simple application which uses it.

My goal in this article will be to build a simple Ember application with a RESTful backend (in Rails) which provides authentication and user registration. We will also set all requests to pass the access token to our backend for authorization.

Here are a couple of the resources I used to build this app:

Our application is going to be using the Rails::API (see Railscast) gem. By using this gem, we limit our Rails app to include only things necessary for API-driven apps. We will also be using Rails 4.0.

We are going to use the active_model_serializers gem to format our JSON responses to be Ember-friendly. We will also use has_secure_password so let’s uncomment the ‘bcrypt’ gem in our Gemfile:

Now install the gems:

We are going to have two models in our application: user and api_key. The user will contain the user information including the encrypted password and the api_key will contain the access token and expiration date. The reason we have separated these two tables is to allow a user to have multiple sessions at a time.

Create the resources.

Run your migrations:

Because we are using the Active Model Serializers gem, serializers are created automatically for our models. However, we want to limit what they return to only the parts which are useful. Update the serializers as follows:

Now let’s add a couple of tests for our models. Update the fixtures for users so we have a user to work with:

We also want to add a couple of fixtures for the api keys:

Add a test to ensure the api_key generates an access token when created.

For this to pass, we need to update the api_key model:

Run your tests and they should pass:

Now let’s add a test to our user and the accompanying code to make it work:

Tests still pass?

Now that we have our database set up how we want it, let’s make it accessible via an API. Here are the parts we want to be able to accomplish:

Let’s start off by adding our authorization layer in our Application controller:

Now let’s set up our users controller:

Now create a session controller and place our code for authenticating an existing user into it.

Update your routes file to make sure that it reflects our changes:

Let’s write some tests to make sure our API is functioning as we expect it to. First, let’s test out our session controller (for authentication):

Now, let’s add some tests to our users controller (for registration):

That was a lot! Let’s run our tests and make sure everything passes.

If you have not yet gone through Part 1 and Part 2, I recommend you do. You can check out the code up to this point with the following:

Also, make sure you run ./bin/ember_build.sh in a separate tab.

So far, we have created an Ember application with a RailsAPI backend and can register, login and logout. There are a few more things that we want to be able to do before we can call it a wrap on this series.

Believe it or not, this is already happening. If you look at auth_manager.js, you will see that in the authenticate function, we add the headers to each AJAX request with the access token.

Let’s test this.

Open up the top_secret route and load place the user list into the controllers model:

Now update the top_secret template with the following:

Users (Top Secret Stuff)

Refresh the browser and click on the Top Secret nav item. If you haven’t already registered and/or logged in, do it first.

If you view the console when loading this page, you will see the network request made to /users. In this request, you can see the headers sent out, one of which is the Authorization header. If this wasn’t there, we would not be able to see a list of users. Click ‘Logout’ and then go to the Top Secret page again. See? You get a 401 Unauthorized response from /users.

It seems rather silly for us to be able to click on the Top Secret nav item and see an empty list of users. Let’s require the user to be authenticated in order to view that page.

The easiest way to do this is to create a base route which can be extended by routes which require authentication. Create a new route called authenticated.

Now modify the sessions/new controller and redirect to the attemptedTransition if available:

Finally, update the top_secret route to extend the new AuthenticatedRoute:

Refresh your browser and click on the Top Secret nav item. You should be redirected to the login page. Now log in and it should redirect you right back to the top secret page.

The final thing I am going to cover (briefly) is performing form validation. This is very simple considering our backend is already giving us what we need. Open up the user.js model and add ‘errors’ as an attribute:

Now open up the users/new controller and capture the errors on a failed registration and place them into the errors hash:

Finally, update the registration template:

Register

Refresh the browser and play around with the form. You should see error messages on submit if they are invalid. These errors are provided by Rails on the backend and are returned via the API.

Thanks for sticking through this with me. The final code can be found at https://github.com/cavneb/simple_auth.

I especially want to thank all those who are taking the time to teach Ember via blogs, screencasts and live presentations. I find myself struggling less and less every day because new content comes out from all of you. Thanks!

In a recent app I have written in Ember, I found that the need to display flash messages came up. This has always been given to me for free with Rails, so I didn’t really think of it not being just as easy to integrate using Ember. I was wrong.. well, sort of wrong.

On searching the web for ‘ember flash’, I found a nice little library at https://github.com/cheapRoc/ember-flash by cheapRoc. After some minor tweaking and customization, I was able to get it working in my app.

In this post, I want to share how easy it is to integrate and offer a little explanation as to how it works.

Instead of creating four different files (controller, message, queue and view), I found that placing all of the same file made sense. I created the file flash.js:

A FlashMessage is an Ember object (lines 1-13) which contains the message text and type of message (notice, warning, error). These messages are added into the FlashQueue, which is an array proxy, via the pushFlash function (lines 75-59). There is an observer (lines 83-85) which triggers the function contentChanged whenever a message is added to the queue. When the contentChanged function is called, it places the flash message into the FlashController’s content (lines 68-74). There is an observer watching the content of the controller (lines 55-64) which displays the FlashView for a short period of time, then hides it (lines 58-59). Once hidden, clearContent is called which hides the view and removes the message from the queue (lines 46-53).

On lines 27-43 above, there are animations set up for when the view is to be shown and hidden. These can be modified to anything. What happens in this code is the view will slide down and fade into view. The reverse happens when it is hidden.

Here is the CSS that I am using:

First, you must include the JavaScript and CSS above in your app.

Second, add the view into your template (e.g. application.handlebars)

Application

Finally, trigger messages to be shown with the pushFlash function:

JS Bin

Authentication with Ember is difficult. I have spent a couple of weeks trying out different approaches and failing time and again. With the help of Ryan Florence and Brad Humphrey, I have finally been able to understand how it should work and also have built a simple application which uses it.

My goal in this article will be to build a simple Ember application with a RESTful backend (in Rails) which provides authentication and user registration. We will also set all requests to pass the access token to our backend for authorization.

Here are a couple of the resources I used to build this app:

Our application is going to be using the Rails::API (see Railscast) gem. By using this gem, we limit our Rails app to include only things necessary for API-driven apps. We will also be using Rails 4.0.

We are going to use the active_model_serializers gem to format our JSON responses to be Ember-friendly. We will also use has_secure_password so let’s uncomment the ‘bcrypt’ gem in our Gemfile:

Now install the gems:

We are going to have two models in our application: user and api_key. The user will contain the user information including the encrypted password and the api_key will contain the access token and expiration date. The reason we have separated these two tables is to allow a user to have multiple sessions at a time.

Create the resources.

Run your migrations:

Because we are using the Active Model Serializers gem, serializers are created automatically for our models. However, we want to limit what they return to only the parts which are useful. Update the serializers as follows:

Now let’s add a couple of tests for our models. Update the fixtures for users so we have a user to work with:

We also want to add a couple of fixtures for the api keys:

Add a test to ensure the api_key generates an access token when created.

For this to pass, we need to update the api_key model:

Run your tests and they should pass:

Now let’s add a test to our user and the accompanying code to make it work:

Tests still pass?

Now that we have our database set up how we want it, let’s make it accessible via an API. Here are the parts we want to be able to accomplish:

Let’s start off by adding our authorization layer in our Application controller:

Now let’s set up our users controller:

Now create a session controller and place our code for authenticating an existing user into it.

Update your routes file to make sure that it reflects our changes:

Let’s write some tests to make sure our API is functioning as we expect it to. First, let’s test out our session controller (for authentication):

Now, let’s add some tests to our users controller (for registration):

That was a lot! Let’s run our tests and make sure everything passes.

If you have not yet gone through Part 1, I recommend you do. You can check out the code up to this point with the following:

I have created Ember applications using a variety of shortcuts (Yeoman, ember-rails) but have found that Ember Tools is by far the best option available. It allows me to skip the Asset Pipeline completely and work directly in my public folder.

To get started, install Ember Tools using npm.

Once this is installed, you will be able to use the console command ember. Try it out:

Excellent. Now create our Ember app in our public directory with the following command:

With that simple command we now have a nearly functional Ember application. Let’s move the generated index.html file into the public folder and modify it a tiny bit.

Note that the only thing that changed in this file is the path to the application.js file. Go ahead and start up your Rails application and visit http://localhost:3000.

You shouldn’t see anything come up and will likely see an error in the server logs. This is because the page is trying to load application.js when it does not exist. To create the file, run (in another terminal tab within the same root directory):

This created three files: templates.js, index.js and application.js. The two former are used temporarily to create the latter. Now refresh your browser and you should see the starter app:

Running ember build can get very tedious, so let’s create a script which will monitor the file structure and run the command when needed. You will need to have fsmonitor installed if you don’t already:

Create the file bin/ember_build:

Now in a separate tab, make the file executable and run it:

Now whenever we change our Ember app, the code will re-compile.

Ember Tools comes with generators, which I LOVE! Let’s create some files using the generators and fill out our layout page.

Start by creating the route, handlebars template and object controller for users/new. This will be where we register.

Now create the route, handlebars template and object controller for sessions/new. This will be where we login.

Finally, create a page which is TOP SECRET and will require authentication to access. Let’s use an array controller so we can list the users.

Update the application handlebars template to show links to the different pages.

Before these links will work we need to add the routes to the config/routes.js file:

Refresh the browser and you should see something like this:

Add some style with twitter bootstrap by adding the CSS link in your index.html page:

Refresh. You can click on the links as well and you should see the correct pages load.

At the moment, Ember Tools does not provide the latest version of Ember Data, so we will need to add this manually. Save the following file to the path public/javascripts/vendor:

Now update a your main application config file to make sure we are using the latest:

On the blog post found at * http://log.simplabs.com/post/53016599611/authentication-in-ember-js , Marco Otte-Witte (@simplabs) created a simple AuthManager which stores and handles authentication. It is very elegant and once I found this post, I got very excited. I made some minor tweaks to the code, but it is still largely intact.

Create a file in your public/javascripts/config folder called auth_manager.js:

For this to work, we will need to add include jquery.cookies into our app. Download https://raw.githubusercontent.com/carhartl/jquery-cookie/master/src/jquery.cookie.js into the folder public/javascripts/vendor and update the app.js file:

Now create the application router and add the AuthManager to the App in the init function. The reason it goes here is because it’s the first thing that gets run after all the code has been loaded.

Let’s create the parts of our app which will allow a user to register. We want to start off by creating a user model which uses Ember Data:

While we’re here, let’s also create the model for api_key:

For us to use Ember Data, we need to enable it. By default with Ember Tools, the localstorage adapter is enabled by default. Let’s remove that and set the adapter to the REST adapter. Open up config/store.js and make the following changes:

Open up our route for new users and set the model to be a new User record:

Modify the users/new controller with the following:

Now let’s update the handlebars template to show the registration form:

Register

Refresh your browser and fill out the registration form and hit submit. You should be logged in and redirected to the index page.

In your JavaScript console, you can view the currently logged in user with the following:

We’re doing great. We now have created an account. However, the UI hasn’t changed. We want to be told that we are logged in and be given the option to log out.

Let’s create an application controller with some computed properties which we will use in the template:

Now modify the application handlebars template to show the menu based on whether the user is authenticated or not:

Now when we reload the browser it will show our email address when we are logged in with a link to log out. Try it out.

We have an action set up in our application template to log out, but we don’t have an event to handle it yet. Let’s put this in the application route.

Refresh your browser and click ‘Logout’. Works? YAY!!!

Let’s start by updating our the session/new route to assign an Ember Object as the controller’s model:

Now update the sessions/new controller to perform the login:

Finally, update the handlebars template to show the login form:

Login

Refresh your browser and log in. On success, you should be redirected to the index page and the nav bar should indicate you are logged in.

If you have not yet gone through Part 1 and Part 2, I recommend you do. You can check out the code up to this point with the following:

Also, make sure you run ./bin/ember_build.sh in a separate tab.

So far, we have created an Ember application with a RailsAPI backend and can register, login and logout. There are a few more things that we want to be able to do before we can call it a wrap on this series.

Believe it or not, this is already happening. If you look at auth_manager.js, you will see that in the authenticate function, we add the headers to each AJAX request with the access token.

Let’s test this.

Open up the top_secret route and load place the user list into the controllers model:

Now update the top_secret template with the following:

Users (Top Secret Stuff)

Refresh the browser and click on the Top Secret nav item. If you haven’t already registered and/or logged in, do it first.

If you view the console when loading this page, you will see the network request made to /users. In this request, you can see the headers sent out, one of which is the Authorization header. If this wasn’t there, we would not be able to see a list of users. Click ‘Logout’ and then go to the Top Secret page again. See? You get a 401 Unauthorized response from /users.

It seems rather silly for us to be able to click on the Top Secret nav item and see an empty list of users. Let’s require the user to be authenticated in order to view that page.

The easiest way to do this is to create a base route which can be extended by routes which require authentication. Create a new route called authenticated.

Now modify the sessions/new controller and redirect to the attemptedTransition if available:

Finally, update the top_secret route to extend the new AuthenticatedRoute:

Refresh your browser and click on the Top Secret nav item. You should be redirected to the login page. Now log in and it should redirect you right back to the top secret page.

The final thing I am going to cover (briefly) is performing form validation. This is very simple considering our backend is already giving us what we need. Open up the user.js model and add ‘errors’ as an attribute:

Now open up the users/new controller and capture the errors on a failed registration and place them into the errors hash:

Finally, update the registration template:

Register

Refresh the browser and play around with the form. You should see error messages on submit if they are invalid. These errors are provided by Rails on the backend and are returned via the API.

Thanks for sticking through this with me. The final code can be found at https://github.com/cavneb/simple_auth.

I especially want to thank all those who are taking the time to teach Ember via blogs, screencasts and live presentations. I find myself struggling less and less every day because new content comes out from all of you. Thanks!