- SQLite

Using Padrino with Ember CLI Part 5: Realtime

2015-03-12T00:00:00+00:00

Note: This article was updated on 8th April 2015 thanks to Phil</a> from Pusher</a> with a better solution for preventing duplicate data. You can see the content of the original post here</a>.

In the final installment of my Padrino + Ember series I'd like to show you how to get some basic realtime functionality within our application. We'll be using Pusher</a> to send and receive messages. They have a pretty reasonable free package which includes 100k messages per day, 20 max connections and SSL if you need it.

You can view the full source for the application on Github</a>

Make sure you've signed up at pusher.com</a>, make an application and make a note of your app_id, key and secret key.

Padrino</h2>
Add the Pusher gem to your Gemfile</code> and run bundle install</code>.
gem 'pusher' </code></pre>
Inside your App class in app/app.rb</code> add the following configuration block with your Pusher credentials. For production I do recommend storing these with dotenv</a> but I'll leave that for you to decide.
configure do Pusher.app_id = '' Pusher.key = '' Pusher.secret = '' end </code></pre> Here are the changes to the posts controller # app/controllers/posts.rb # ... post :create, map: "" do parameters = post_params if parameters["post"].nil? return '{}' end @post = Post.create parameters["post"].except("socket_id") Pusher['posts'].trigger('new-post', {post: @post.values}, parameters["post"]["socket_id"]) render "posts/show" end # ... put :update, map: ":id" do @post = Post[params[:id]] if @post.nil? return '{}' end parameters = post_params @post.update parameters["post"].except("socket_id") render "posts/show" end # ... </code></pre> We're going to be sending a new parameter called socket_id</code> to our Padrino API from the Ember application. socket_id</code> is generated from Pusher in the Ember application and is unique for each user. Notice on lines 8 and 25 we exclude socket_id</code> as we don't have a socket_id</code> field in our posts table to insert. On line 10 we send the data to Pusher to tell applications that there is a new blog post. The key, posts</code>, is the channel. The first parameter new-post</code> is the event, the second parameter is the data to send and the third parameter is client's socket id. Sending the client's socket id means that Pusher will not send the event back to the user which created it. This will prevent duplicate data from showing in the poster's Ember application. That's it for Padrino. It's really that simple! Before moving onto the Ember part of the application make sure that Pusher is receiving the messages. The easiest way to do this is to create a post in the Ember app and then go to the debug log in the Pusher dashboard. Ember</h2> We need to install 2 addons for Ember. One of which is for Pusher and can be installed via command line ember install:addon ember-cli-pusher</code> The other is to deal with CSP (Content Security Policy) when using Pusher. Without it we will get an error from our application like the following [Report Only] Refused to load the script 'http://stats.pusher.com/timeline/v2/jsonp/1?session=...' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval' localhost:35729 0.0.0.0:35729".</code> To fix this we use ember-cli-content-security-policy</code>. Let's add it to our package.json</code>. Currently we can't install it via command line because there's a bug in the latest tagged release. We need to get the latest version from Github. "ember-cli-content-security-policy": "git://github.com/rwjblue/ember-cli-content-security-policy.git#master", </code></pre> Run npm install</code> afterwards. Next we'll update config/environment.js</code>. Make sure you put your Pusher key in the Pusher settings. APP: { // Here you can pass flags/options to your application instance // when it is created PUSHER_OPTS: { key: '<YOURKEY>', connection: {}, logAllEvents: false } }, </code></pre> We can add these CSP settings with the other ENV related content. Note that Bootstrap CDN is also included for fonts and stylesheets. ENV['contentSecurityPolicy'] = { 'default-src': "'none'", 'font-src': "'self' http://maxcdn.bootstrapcdn.com/", 'script-src': "'self' http://stats.pusher.com/", 'connect-src': "'self' ws://ws.pusherapp.com/", 'img-src': "'self'", 'style-src': "'self' 'unsafe-inline' http://maxcdn.bootstrapcdn.com/", 'media-src': "'self'", }; </code></pre> Now that we have Pusher set up we need to generate the controller for the posts/index and modify it to receive the events. ember g controller posts/index </code></pre> In app/controllers/posts/index.js</code> add the following: import Ember from 'ember'; import { Bindings } from 'ember-pusher/bindings'; export default Ember.ArrayController.extend(Bindings, { sortProperties: ['id'], sortAscending: false, logPusherEvents: true, PUSHER_SUBSCRIPTIONS: { posts: ['new-post'] }, actions: { newPost: function(message) { this.store.push('post', this.store.normalize('post', message.post)); } } }); </code></pre> We will switch the controller to an ArrayController so we can sort by id</code> descending (so that newer posts appear at the top). Using the pusher library we subscribe to the posts channel and the new-post</code> event. Note that when there is a new-post</code> event an action is called with the camel-case version of the name. In this case new-post</code> becomes newPost</code>. Inside of the newPost</code> action we use store.push</code> which will find the post if it's already there or create it otherwise. Here is the newly updated posts/index.hbs</code> <h3>Latest Posts</h3> <table class="table table-striped"> <tr> <th class=“col-md-3”>Title</th> <th class="col-md-3">Created at</th> <th class="col-md-3">Last modified</th> <th class="col-md-3">Actions</th> </tr> {{#each post in arrangedContent}} <tr> <td>{{ post.title }}</td> <td>{{ post.createdAt }}</td> <td>{{ post.updatedAt }}</td> <td> {{#link-to 'posts.show' post classNames="btn btn-success"}}View{{/link-to}} {{#if session.isAuthenticated}} {{#link-to 'posts.edit' post classNames="btn btn-info"}}Edit{{/link-to}} <button {{action 'delete' post}} class="btn btn-danger">Delete</button> {{/if}} </td> </tr> {{/each}} </table> {{#if session.isAuthenticated}} {{#link-to 'posts.new' classNames="btn btn-primary"}} New Post {{/link-to}} {{/if}} </code></pre> Note that we're looping through arrangedContent</code> now so that we that the data is ordered by ID descending. At this point posts will get pushed to the on top until we hit an id of 10 which mysteriously goes to the bottom of the collection. This is because Ember's sort works with strings not integers. The simplest solution is to switch id</code> out for createdAt</code> in your posts/index</code> controller. sortProperties: ['createdAt'], </code></pre> As mentioned in the Padrino part of the article we need to add a new parameter, socketId</code> to the post</code> model. // app/models/post.js import DS from 'ember-data'; export default DS.Model.extend({ title: DS.attr('string'), content: DS.attr('string'), createdAt: DS.attr('string'), updatedAt: DS.attr('string'), socketId: DS.attr('string') }); </code></pre> socketId</code> will need to be sent when we create a new post. To do this we need to edit the save</code> action in app/routes/posts/new.js</code>. // ... actions: { save: function() { var _this = this; var post = this.modelFor('posts/new') post.set('socketId', this.pusher.get('socketId')); post.save().then(function() { _this.transitionTo('posts.index'); }); } } // ... </code></pre> Notice how we get the model and assign the pusher socketId</code> before saving it to the server. Notification messages</h3> Maybe you don't want new data to be pushed on top all of the time. This is a valid opinion, especially when considering the end user - who might be in the middle of reading a particularly long title. They might not appreciate the browser scrolling down all of the time and losing their place. At this point I think something similar to how Twitter's website deals with new tweets would be ideal. We'll show a little box with a message saying "1 New Post" and allow the user to click it to insert any new posts. In app/controllers/posts/index.js</code> update the code to the following import Ember from 'ember'; import { Bindings } from 'ember-pusher/bindings'; export default Ember.ArrayController.extend(Bindings, { sortProperties: ['createdAt'], sortAscending: false, logPusherEvents: true, PUSHER_SUBSCRIPTIONS: { posts: ['new-post'] }, newPosts: [], newPostCount: function() { return this.get('newPosts.length'); }.property('newPosts.length'), newPostsExist: function() { return !!this.get('newPostCount'); }.property('newPostCount'), newPostMessage: function() { var wording = (this.get('newPostCount') !== 1) ? "New Posts" : "New Post"; return this.get('newPostCount') + " " + wording; }.property('newPostCount'), actions: { newPost: function(message) { if(!this.store.hasRecordForId('post', message.post.id)) { this.get('newPosts').pushObject(message.post); } }, refresh: function() { this.get('newPosts').forEach(function(post) { this.store.push('post', this.store.normalize('post', post)); }, this); this.set('newPosts', []); } } }); </code></pre> On line 11 we have a new property newPosts</code> which by default is an empty array. Every time a new post is sent to Ember we will store it in here. On line 12-14 we have a computed property called newPostCount</code> which counts the number of posts we have stored in the newPosts</code> array. On lines 15-17 we have a computed property called newPostsExist</code> which returns a boolean value for our template. The double exclamation mark converts the newPosts</code> length to false if it's 0 and true otherwise. Lines 18-21 sets up the message we want to display to the user when a new post is available. This will be either "1 New Post" or "x New Posts". In the newPost</code> action on lines 23-27 instead of pushing the post into the store we put it in the newPosts</code> array for later. The refresh action on lines 28-33 will be a click event in our template which takes each post and pushes them into our store. The newPostCount</code> computed property has the following code: newPosts.length</code>. This allows it to watch for when the newPosts</code> array has changed in length. With this we can update the user with how many new posts there are automatically. Here is the new template in app/templates/posts/index.hbs</code> <h3>Latest Posts</h3> {{#if newPostsExist}} <div class="alert alert-info click" {{action 'refresh'}}> {{ newPostMessage }} </div> {{/if}} <table class="table table-striped"> <tr> <th class=“col-md-3”>Title</th> <th class="col-md-3">Created at</th> <th class="col-md-3">Last modified</th> <th class="col-md-3">Actions</th> </tr> {{#each post in arrangedContent}} <tr> <td>{{ post.title }}</td> <td>{{ post.createdAt }}</td> <td>{{ post.updatedAt }}</td> <td> {{#link-to 'posts.show' post classNames="btn btn-success"}}View{{/link-to}} {{#if session.isAuthenticated}} {{#link-to 'posts.edit' post classNames="btn btn-info"}}Edit{{/link-to}} <button {{action 'delete' post}} class="btn btn-danger">Delete</button> {{/if}} </td> </tr> {{/each}} </table> {{#if session.isAuthenticated}} {{#link-to 'posts.new' classNames="btn btn-primary"}} New Post {{/link-to}} {{/if}} </code></pre> We bind the click event refresh</code> to the new alert so when a user clicks the message they receive the new posts and the alert gets removed. Feel free to add some CSS or use anchor tags so that the cursor changes on hover and encourages the user to click! .click { cursor: pointer; cursor: hand; } </code></pre> Summary</h2> In this post we've covered 2 ways of using Pusher to handle notifications. One where new posts get added directly to the store and another where we hold on to changes and let the user handle updates. I hope you have enjoyed this series and learned how awesome it is to use Padrino with Ember. Don't forget to check out the full source on Github</a>!

Using Padrino with Ember CLI Part 4: Authorisation 2015-03-03T00:00:00+00:00 In the last article I went through how to implement authorisation with Ember-simple-auth and Padrino. The next logical step is to implement authorisation with the same toolset. You can view the full source for the application on Github</a> Ember</h2> On the Ember side of things it couldn't be easier to implement. All we need to do is open up our configuration (app/config/environment.js</code>) and add the authorizer</code> property to our simple-auth</code> environment variable. ENV['simple-auth'] = { routeAfterAuthentication: 'posts.index', routeIfAlreadyAuthenticated: 'posts.index', authorizer: 'simple-auth-authorizer:devise' }; </code></pre> Let's take a look at the header request for the posts API when we aren't logged in </a> Now let's compare that to when we are logged in </a> As you can see: authorisation is sent with our email and our token. This will occur on every request so it's up to you to decide with Padrino which API requests need guarding or filtering. Before we move on to the Padrino section of this article I think it's important for you to be aware of one important feature of Ember-data. By convention Ember will use something similar to this line of code to fetch a specific post. store.find('post', 15) </code></pre> This request queries the server if the post hasn't already been loaded. If the user has viewed the list of posts then it will have been. Therefore there will be no authorisation checks. With this in mind make sure that you filter out data in the API rather than in Ember. Padrino</h2> I want to mention a sweet tip when working with APIs in Ruby. return JSON.pretty_generate(request.env) </code></pre> If you can't find something that you think should be in the request there is no nicer way of formatting your request. There's also the pretty print</a> library but that will only give you output in your command line. Ember-simple-auth-devise sends the following to our API when we're logged in "Token authentication_token="gDXbsrbDq2H9CKKG42Ts0A", email="admin@admin.co.uk"" </code></pre> It isn't the easiest string to parse but taking a little inspiration from Rail's HttpAuthentication module</a> I came out the other end with this as my models/user.rb</code> file. require 'bcrypt' require 'securerandom' class User < Sequel::Model Sequel::Model.plugin :timestamps attr_reader :readable_token def before_create self.password = BCrypt::Password.create(self.password) generate_authentication_token end def self.sign_in credentials user = self.first(email: credentials.fetch("email", "")) return false unless user return false if BCrypt::Password.new(user.password) != credentials.fetch("password", "") user.generate_authentication_token user.save return user end def generate_authentication_token(user=false) self.authentication_token = SecureRandom.urlsafe_base64(nil,false) @readable_token = self.authentication_token self.authentication_token = BCrypt::Password.create(self.authentication_token) return end def self.authenticate(environment, parser=AuthorizationStringParser) credentials = parser.new(environment).parsed_string return false if credentials.nil? user = self.where(email: credentials.fetch("email", "")).first return false unless user return BCrypt::Password.new(user[:authentication_token]) == credentials.fetch("authentication_token", "") end end class AuthorizationStringParser attr_accessor :parsed_string, :environment def initialize(environment) @environment = environment end def parsed_string parsed_string ||= parse_string end protected def parse_string raw_param_string = environment.fetch("HTTP_AUTHORIZATION", "") raw_param_string.gsub(/Token\s|"|,/, "").split(' ').map { |key_value| key_value.split(%r/=(.+)?/) }.to_h end end </code></pre> On lines 32-38 we have the new self.authenticate</code> method which takes the request.env</code> (or any hash for that matter). I chose pass the environment in as request</code> is not available in the model and I didn't feel it was the controller's responsibility to handle parsing the token string. It's also much nicer to just call User.authenticate request.env</code> and let the model sort out the details. You could argue that it's not the model's responsibility to do this either. If the application was larger I would consider creating a user repository to do it instead. On line 32 we reference a new class (which is defined on lines 41-56) . This AuthorizationStringParser</code> is responsible for... parsing the authorisation string. Between 34 and 36 we check if the credentials exist and if the user's email exists in our database. Finally on line 37 we use Bcrypt</code> to check if the token that's sent is valid. Now we should open up our posts controller at app/controllers/posts.rb</code> and set the appropriate permissions for our API. require 'json' Api::App.controllers :posts, map: "api/v1/posts", conditions: {:protect => true} do def self.protect(protected) condition do unless User.authenticate request.env halt 403, "No secrets for you!" end end if protected end get :index, map: "", protect: false do @posts = Post.all render "posts/index" end post :create, map: "" do parameters = post_params if parameters["post"].nil? return '{}' end @post = Post.create parameters["post"] render "posts/show" end get :show, map: ":id" do @post = Post[params[:id]] render "posts/show" end put :update, map: ":id" do @post = Post[params[:id]] if @post.nil? return '{}' end parameters = post_params @post.update parameters["post"] render "posts/show" end delete :destroy, map: ":id" do @post = Post[params[:id]] @post.delete unless @post.nil? end end def post_params JSON.parse(request.body.read) end </code></pre> On line 3 we've added a new parameter, conditions: {:protect => true}</code> and on lines 5-11 there's a new self.protect</code> method which will be called before every route in the controller. This is where we take advantage of our new User.authenticate</code> method and return a 403 error for invalid authorisation requests. On line 13 and 27 we have disabled protection so that the posts can be accessed with out being logged in. All of the other routes that edit the data require authorisation. Tests</h3> We best add some tests for our new authenticate method. Open up test/models/user_test.rb</code> and add the following. it "returns true when valid" do params = { "email" => "admin@admin.co.uk", "password" => "testpassword"} user = User.sign_in params authenticated = User.authenticate({"HTTP_AUTHORIZATION" => "Token authentication_token=\"#{user.readable_token}\", email=\"#{user.email}\""}) assert_equal true, authenticated end it "returns false when invalid" do params = { "email" => "admin@admin.co.uk", "password" => "testpassword"} user = User.sign_in params User.sign_in params authenticated = User.authenticate({"HTTP_AUTHORIZATION" => "Token authentication_token=\"#{user.readable_token}\", email=\"#{user.email}\""}) assert_equal false, authenticated end it "returns false if no header is sent" do params = { "email" => "admin@admin.co.uk", "password" => "testpassword"} user = User.sign_in params User.sign_in params authenticated = User.authenticate({}) assert_equal false, authenticated end </code></pre> Tidying up Ember</h2> At this point our authorisation is in place but it's hardly a good idea to leave all those buttons for adding, editing and deleting data lying around. Let's change app/templates/posts/index.hbs</code> to hide these buttons when the user's aren't logged in. <h3>Latest Posts</h3> <table class="table table-striped"> <tr> <th class=“col-md-3”>Title</th> <th class="col-md-3">Created at</th> <th class="col-md-3">Last modified</th> <th class="col-md-3">Actions</th> </tr> {{#each post in model}} <tr> <td>{{ post.title }}</td> <td>{{ post.createdAt }}</td> <td>{{ post.updatedAt }}</td> <td> {{#link-to 'posts.show' post classNames="btn btn-success"}}View{{/link-to}} {{#if session.isAuthenticated}} {{#link-to 'posts.edit' post classNames="btn btn-info"}}Edit{{/link-to}} <button {{action 'delete' post}} class="btn btn-danger">Delete</button> {{/if}} </td> </tr> {{/each}} </table> {{#if session.isAuthenticated}} {{#link-to 'posts.new' classNames="btn btn-primary"}} New Post {{/link-to}} {{/if}} </code></pre> We have already disabled viewing the new posts route in a previous article. We should do the same for the edit posts, too. Open up app/routes/posts/edit.js</code> and add the AuthenticatedRouteMixin</code>. import Ember from 'ember'; import AuthenticatedRouteMixin from 'simple-auth/mixins/authenticated-route-mixin'; export default Ember.Route.extend(AuthenticatedRouteMixin, { deactivate: function() { var model = this.modelFor('posts/edit'); model.rollback(); }, actions: { save: function() { var _this = this; this.modelFor('posts/edit').save().then(function() { _this.transitionTo('posts.index'); }); } } }); </code></pre> Here are two previews of the system. One logged in and one logged out. </a> </a> Summary</h2> That's it for authorisation with Ember and Padrino! We've covered setting up Ember to use the ember-simple-auth devise authoriser and updated our Padrino application which now reads the request headers to check for valid authentication details. We've also restricted specific routes to users that are logged in and updated the Ember front-end to reflect these changes. Using Padrino with Ember CLI Part 3: Authentication 2015-02-22T00:00:00+00:00 While thinking about what to write for this week's article it occured that I never touched on authentication with Ember and Padrino in my previous articles. So I think this is the perfect excuse to continue with the series! Follow along for creating a Padrino backend that works with Ember-simple-auth and the authentication library Ember-simple-auth-devise. You can view the full source for the application on Github</a> Setting up the API</h2> Before we start our deep dive into authentication open up your Gemfile, add bcrypt and run bundle install</code>. gem 'bcrypt-ruby', '~> 3.1.5' </code></pre> We'll start by generating the User</code> model which will have 6 fields: id</code>, email</code>, password</code>, authentication_token</code>, created_at</code> and updated_at</code> padrino g model User email:string password:string authentication_token:string created_at:datetime updated_at:datetime </code></pre> Now we can run the migration: rake sq:migrate:up </code></pre> We need to make some changes to the model. Open models/user.rb</code> and add the following code require 'bcrypt' require 'securerandom' class User < Sequel::Model Sequel::Model.plugin :timestamps attr_reader :readable_token def before_create self.password = BCrypt::Password.create(self.password) generate_authentication_token end def self.sign_in credentials user = self.first(email: credentials.fetch("email", "")) return false unless user return false if BCrypt::Password.new(user.password) != credentials.fetch("password", "") user.generate_authentication_token user.save return user end def generate_authentication_token(user=false) self.authentication_token = SecureRandom.urlsafe_base64(nil,false) @readable_token = self.authentication_token self.authentication_token = BCrypt::Password.create(self.authentication_token) return end end </code></pre> Just like the Post</code> model we need to include the timestamps plugin so that our created_at</code> and updated_at</code> fields update appropriately. Second, we need to add a before_create</code> hook which generates an authentication token and hashes our passwords for us. Third, we have added a static method for signing in. This will take one parameter which is a hash of email and password. It will return an instance of User</code> if valid and false</code> otherwise. Lastly, we've added a generate_authentication_token</code> which handles the token generation. Because we should never store the token directly in the database we have to hash it. That puts us in a predicament. How do we read the token but also make sure it's hashed in the database? We could do a before_save</code> hook which automatically hashes unhashed tokens but what if we want to access the token after a save? We would be forced to invalidate a user's session and things start to get messy. My solution is to create an instance variable named readable_token</code> which gets a copy of the token before it's hashed. This property is not placed in the database but is accessible after a token is generated for the remainder of the session. This means 3 things: The database always has the correct token because it's always saved straight after generation.</li> We have access to the token after generation which let's us use the token for the remainder of the session.</li> If a user sends a separate request we will not have access to the readable token. This encourages us to check authorisation requests against the database hash rather than trying to do a sneaky shortcut and comparing it to the readable token.</li> </ul> For token generation we're using SecureRandom.urlsafe_base64(nil, false)</code>. According to this StackOverflow thread</a> Rails has now deprecated this method in favour of base58. I've tried to get base58 working but failed miserably. At the time of writing I believe base58 is in the Rails/ActiveSupport master branch where as Padrino uses ActiveSupport 4.2. I may come back to this in the future. Let's seed a couple of users into our database to test everything's working. By default the Padrino seed command looks for a db/seed.rb file and runs it. I prefer to keep separate files for each model. So in db/seeds.rb put the following Dir[__dir__ + '/seeds/**/*.rb'].each {|file| require file} </code></pre> And then create db/seeds/user.rb</code>. In this file we'll truncate the database and create two users. User.truncate User.create({ email: "admin@admin.co.uk", password: "testpassword", }) User.create({ email: "example@example.co.uk", password: "testpassword", }) </code></pre> Tip: Other Sequel methods such as multi_insert</code> will ignore the before_create</code> hook which means we don't get a hashed password or authentication token. When we run padrino rake seed</code> we can see the data that's been inserted into the database including our hashed passwords and authentication tokens It's time to move on to the controller app/controllers/users.rb</code>. Api::App.controllers "api/v1/users" do post :sign_in do user = User.sign_in params.fetch("user", {}) if user @status = 201 else @message = "Invalid login credentials" unless user @status = 401 end @user = user status @status render "users/sign_in" end end </code></pre> Ember will be sending a user</code> object which contains email</code> and password</code> key values. If the user exists we want the request to return a status of 201 for successful creation. If the credentials are invalid we set a message which will be passed to our RABL template. Let's place the RABL template in app/views/users/sign_in.rabl</code> object @user => false attributes :readable_token => :authentication_token, :email => :email node (:message) {|m| @message } </code></pre> We want to use the user object but we don't want the default behaviour of wrapping "user" around our attributes so we set it to false</code>. Also notice how we're mapping readable_token</code> to authentication_token</code> for Ember. The node</code> block let's us add another attribute not associated with the user. This message will host our error message to show the user. Here's a couple of screenshots of how we can interact with the API via Postman APP and the structure of the JSON returned. Success</h3> Failed</h3> Testing</h2> So far we've done a shameful amount of testing. Well no more! I think at least for authentication it's important we have a few tests in place for peace of mind. When we first generated the project we included MiniTest which Padrino has kindly set up for us. When we run padrino rake test</code> we get a couple of failures due to some helper tests. Go in to test/app/helpers</code> and remove the two files posts_helper_test.rb</code> and users_helper_tests.rb</code>. Running padrino rake test</code> now brings us back to green. Here is our test/app/controllers/users_controller_test.rb</code> require 'json' require File.expand_path(File.dirname(__FILE__) + '/../../test_config.rb') describe "/users" do before do User.create({ email: "admin@admin.co.uk", password: "testpassword", }) end it "should authenticate valid credentials" do post "api/v1/users/sign_in", {"user" => {"email" => "admin@admin.co.uk", "password" => "testpassword"}} json_response = JSON.parse last_response.body assert_equal nil, json_response["message"] assert_equal "admin@admin.co.uk", json_response["email"] assert_includes json_response, "authentication_token" assert_equal 201, last_response.status end it "should authenticate valid credentials" do post "api/v1/users/sign_in", {"user" => {"email" => "admin@admin.co.uk", "password" => "wrongpassword"}} json_response = JSON.parse last_response.body refute_nil json_response["message"] refute_includes json_response, "email" assert_equal 401, last_response.status end end </code></pre> The before block creates a valid User for us to test. From there we have two tests: one for testing valid credentials and one for testing invalid credentials. We test that the correct status and appropriate values are returned. The test/app/models/user_test.rb</code> is a little longer but still rather simple require File.expand_path(File.dirname(__FILE__) + '/../test_config.rb') describe "User Model" do before do @user = User.create({ email: "admin@admin.co.uk", password: "testpassword", }) end it 'can construct a new instance' do user = User.new refute_nil user end it 'generates an authentication_token when created' do refute_nil @user, "authentication_token" refute_nil @user, "readable_token" end it 'generates a new authentication_token when signed in' do params = { "email" => "admin@admin.co.uk", "password" => "testpassword"} user = User.sign_in params readable_token = user.readable_token authentication_token = user.authentication_token user = User.sign_in params refute_equal readable_token, user.readable_token refute_equal authentication_token, user.authentication_token end it 'returns false with invalid credentials' do params = { "email" => "admin@admin.co.uk", "password" => "badpassword"} user = User.sign_in params assert_equal false, user end it "returns false when credentials aren't set" do params = { } user = User.sign_in params assert_equal false, user end end </code></pre> With this set of tests we're mostly focusing on the behaviour of the authentication token. Noteably, on lines 21 to 32 we're checking that signing in a second time regenerates the authentication token. If you're using the Github repo or you want to see green colours fly by then make sure you install minitest-reports</a>. At this point we have some basic tests in place and padrino rake test</code> should return green. Our journey with Padrino is complete but Ember is calling us... Ember</h2> Change directory in to your Ember app and run the following commands. ember install:addon ember-cli-simple-auth ember install:addon ember-cli-simple-auth-devise </code></pre> Ember simple auth requires an authenticator. We could create a custom one but this article is already long enough and Devise does the job. We're already simulating a Rails CRUD app. Why not simulate a Rails authentication library, too? Besides, it's pretty flexible. If we go in to config/environment.js</code> we can customise our authentication library to work with our API. Let's add some code just above the return ENV</code>: ENV['simple-auth-devise'] = { serverTokenEndpoint: '/api/v1/users/sign_in', tokenAttributeName: 'authentication_token', identificationAttributeName: 'email', }; ENV['simple-auth'] = { routeAfterAuthentication: 'posts.index', routeIfAlreadyAuthenticated: 'posts.index' }; </code></pre> serverTokenEndpoint</code> is our API end point for signing in.</li> tokenAttributeName</code> is the name of our authentication token.</li> identificationAttributeName</code> is the field we're sending back with the token to identify the user. In this case we're using the email.</li> routeAfterAuthentication</code> and routeIfAlreadyExists</code> is where to redirect to when necessary. By default this is index</code> but since we made the route of our app posts</code> we have to change it.</li> </ul> Time to whip out some more ember-cli commands. This time we need to make a login controller and two routes. ember g controller login ember g route application ember g route login </code></pre> We'll make a login form with help from this error message example</a>. In app/controllers/login.js</code> import LoginControllerMixin from 'simple-auth/mixins/login-controller-mixin'; import Ember from 'ember'; export default Ember.Controller.extend(LoginControllerMixin, { authenticator: 'simple-auth-authenticator:devise', actions: { // display an error when authentication fails authenticate: function() { var _this = this; this._super().then(null, function(error) { _this.set('errorMessage', error.message); }); } } }); </code></pre> We add the LoginControllerMixin</code> so that this controller will have the methods for authenticating. We override the authenticate action so that we can set our custom error message in the template. In app/routes/application.js</code> we need to include the ApplicationRouteMixin</code> import ApplicationRouteMixin from 'simple-auth/mixins/application-route-mixin'; import Ember from 'ember'; export default Ember.Route.extend(ApplicationRouteMixin); </code></pre> Now we need to change the setupController</code> inside of app/routes/login.js</code> to remove previous error messages. If we dont then when a user fails logging in, goes to another route and then returns to login they will see the previous error message. import Ember from 'ember'; export default Ember.Route.extend({ setupController: function(controller, model) { controller.set('errorMessage', null); } }); </code></pre> It's time we made a navigation bar. Make the partial app/templates/-navigation.hbs</code> <nav class="navbar navbar-default">  <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1"> <ul class="nav navbar-nav"> {{#link-to 'posts.index' tagName='li'}} {{#link-to 'posts.index'}} Posts {{/link-to}} {{/link-to}} {{#if session.isAuthenticated}} <li><a {{ action 'invalidateSession' }}>Logout</a></li> {{else}} {{#link-to 'login' tagName='li'}} {{#link-to 'login'}} Login {{/link-to}} {{/link-to}} {{/if}} </ul> </div> </nav> </code></pre> We have an if statement (if session.isAuthenticated</code>) which let's us show different links depending on whether the user is logged in. Notice the nested link-to</code> tags. Ember adds an active class to the link-to</code> helpers that match the current route but Bootstrap expects this on the list element rather than the anchor tag. The nested link-to</code> resolves this issue for us nicely. Time for us to update our app/templates/application.hbs</code> to include our new partial <div class="row"> <div class="col-md-12"> <h1>Welcome to Ember with Padrino</h1> {{partial "navigation"}} </div> </div> <div class="row"> <div class="col-md-12"> {{outlet}} </div> </div> </code></pre> Finally we can create our Login form. We're almost at the finish line guys! <h2>Login</h2> <form {{action 'authenticate' on='submit'}} class="horizontal"> {{#if errorMessage}} <div class="alert alert-danger"> <p> <strong>Login failed:</strong> <code>{{errorMessage}}</code> </p> </div> {{/if}} <div class="form-group"> <label for="identification" class="control-label">Email</label> {{input value=identification placeholder='Enter Email' classNames="form-control"}} </div> <div class="form-group"> <label for="password" class="control-label">Password</label> {{input value=password placeholder='Enter Password' type='password' classNames="form-control"}} </div> <div class="form-group"> <button type="submit" class="btn btn-primary">Login</button> </div> </form> </code></pre> Any method route that requires authentication can now include the AuthenticationRouteMixin</code> mixin. As an example. Change the app/routes/posts/new.js</code> to the following import Ember from 'ember'; import AuthenticatedRouteMixin from 'simple-auth/mixins/authenticated-route-mixin'; export default Ember.Route.extend(AuthenticatedRouteMixin, { model: function() { return this.store.createRecord('post'); }, deactivate: function() { var model = this.modelFor('posts/new'); if(model.get('isNew')) { model.destroyRecord(); } }, actions: { save: function() { var _this = this; this.modelFor('posts/new').save().then(function() { _this.transitionTo('posts.index'); }); } } }); </code></pre> Now if we try to access the posts/new</code> page without logging in we will be redirected to the login form. Is this production ready?</h2> This article is merely proof of concept. There are a few reasons I would not recommend using this for anything you need to keep secure. This post only covers authentication and not authorization. The authentication part of ember-simple-auth only covers the retrieval of a valid token from a successful log in. It will not check future requests for validity! That's where authorisation comes in which is not covered in this article. I've also gone and rolled my own authentication in Padrino which is not ideal. I have not covered validation of users, making sure that email addresses are unique etc. Your best bet is to try to get Warden working with Padrino for a proper log in system. If you're serious about securing your API, read this StackOverflow post</a> which gives you a list of best practices for securing your tokens. Summary</h2> This was a lot longer than I predicted. I guess I can only blame myself for trying to include both Padrino and Ember in one article! I have covered so much in this article and while I can't speak for you, I can say it's been quite the learning experience for myself. We've covered the security precautions and ramifications of using Ember-simple-auth for authentication, how to implement a Padrino API compatible with the Ember-simple-auth-devise authentication library and giving users feedback on their incorrect logins. We also touched on using MiniTest with Padrino, generating secure tokens in Ruby and restricting access to specific routes with Ember-simple-auth. Next up: Part 4: Authorization</a> Using Padrino with Ember CLI Part 2 2015-02-15T00:00:00+00:00 You can view the full source for this article on Github</a>. I am using the following library versions for this tutorial: IO.js v1.2.0</li> NPM 2.5.1</li> watchman 3.0.0 (Installed with homebrew)</li> Ember 1.8.1</li> Ember Data 1.0.0-beta.14.1</li> jQuery 1.11.2</li> Handlebars 1.3.0</li> </ul> Before starting make sure you’re in your Blog</code> directory and not Blog/API</code>. To create our Ember application we'll use ember new app</code> and then cd into it. Run ember serve --proxy http://localhost:3000</code> so that we can use our API. The proxy URL should match our Padrino API. By default the port for Padrino is 3000. Bootstrap</h2> I’m adding Bootstrap in app/index.html</code> and changing the templates to use bootstrap as well. This is entirely optional. Feel free to use your own CSS / preferred CSS Framework. <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title>App</title> <meta name="description" content=""> <meta name="viewport" content="width=device-width, initial-scale=1"> {{content-for 'head'}} <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/bootstrap/3.3.2/css/bootstrap.min.css"> <link rel="stylesheet" href="assets/vendor.css"> <link rel="stylesheet" href="assets/app.css"> {{content-for 'head-footer'}} </head> <body> <div class="container"> <div id="application"> </div> </div> {{content-for 'body'}} <script src="assets/vendor.js"></script> <script src="assets/app.js"></script> {{content-for 'body-footer'}} </body> </html> </code></pre> In app/app.js</code> we can add the rootElement</code> parameter so that our Ember application gets loaded inside of the container. var App = Ember.Application.extend({ modulePrefix: config.modulePrefix, podModulePrefix: config.podModulePrefix, Resolver: Resolver, rootElement: '#application' }); </code></pre> Finally, in app/templates/application.hbs</code> we’ll add some rows and columns to make use of Bootstrap’s responsive grid. <div class="row"> <div class="col-md-12"> <h2 id="title">Welcome to Ember with Padrino</h2> </div> </div> <div class="row"> <div class="col-md-12"> {{outlet}} </div> </div> </code></pre> Routes</h3> In app/router.js</code> add the following routes: Router.map(function() { this.resource('posts', {path: '/'}, function() { this.resource('posts.new', {path: '/post/new'}); this.resource('posts.show', {path: '/post/:post_id'}); this.resource('posts.edit', {path: '/post/:post_id/edit'}); }); }); </code></pre> This is what our Route should look like in Ember Inspector: </a> Adapter</h3> We can set up the application adapter by running the following command ember g adapter application </code></pre> This will make a new file in app/adapters/application.js</code>. Let’s change the code to work with our API: import DS from 'ember-data'; export default DS.ActiveModelAdapter.extend({ namespace: 'api/v1' }); </code></pre> On line 3 we change the adapter to be the Rails-style adapter. As we’ve set our API to work the same way as Rails we can make use of its conventions. On line 4 we prefix all API requests with api/v1</code> which is how we’ve set it in our API. Routes and Resources</h3> Let’s generate the Post resource, routes and templates. Ember CLI makes this super easy: ember g resource posts title:string content:string createdAt:string updatedAt:string ember g route posts/index ember g route posts/new ember g route posts/show ember g route posts/edit </code></pre> This sets us up with all the files we will need to edit. Note how createdAt</code> and updatedAt</code> are camel case here but snake case in Padrino. The ActiveModelAdapter</code> will take care of this conversion so we don’t have to! In app/routes/posts.js</code> we should tell Ember where to find our posts like so: import Ember from 'ember'; export default Ember.Route.extend({ model: function() { return this.store.find('post'); } }); </code></pre> Index</h2> Let’s update the posts index template in app/templates/posts/index.hbs</code> to iterate over the posts: <h3>Latest Posts</h3> <h3>Latest Posts</h3> <table class="table table-striped"> <tr> <th class=“col-md-3”>Title</th> <th class="col-md-3">Created at</th> <th class="col-md-3">Last modified</th> <th class="col-md-3">Actions</th> </tr> {{#each post in model}} <tr> <td>{{ post.title }}</td> <td>{{ post.createdAt }}</td> <td>{{ post.updatedAt }}</td> <td> {{#link-to 'posts.show' post classNames="btn btn-success"}}View{{/link-to}} {{#link-to 'posts.edit' post classNames="btn btn-info”}}Edit{{/link-to}} <button {{action 'delete' post}} class="btn btn-danger">Delete</button> </td> </tr> {{/each}} </table> {{#link-to 'posts.new' classNames="btn btn-primary"}} New Post {{/link-to}} </code></pre> Nothing too interesting is going on here. We are looping through our model in a Bootstrap-flavoured table. Each post has 2 links, 1 to view the post and 1 to edit. It also has an action to remove the post. None of these do anything as of yet, so let’s get the rest of the application working. New</h2> The posts new route file (app/routes/posts/new.js</code>) will have three jobs: import Ember from 'ember'; export default Ember.Route.extend({ model: function() { return this.store.createRecord('post'); }, deactivate: function() { var model = this.modelFor('posts/new'); if(model.get('isNew')) { model.destroyRecord(); } }, actions: { save: function() { var _this = this; this.modelFor('posts/new').save().then(function() { _this.transitionTo('posts.index'); }); } } }); </code></pre> The model method will create a new instance of post for us in the Ember application. Deactivate will trigger if we switch out of the route without saving. We use this because if we don’t save the the new post to the API (we click cancel) Ember will keep this “dirty” object hanging around in the application. destroyRecord</code> will remove it for us. Lastly we set the save action to create the post and go back to the posts.index route. Modify two templates, app/templates/posts/new.hbs</code> <h3>New Post</h3> {{ partial 'posts/form' }} </code></pre> Our Form partial located in app/templates/posts/-form.hbs</code> <form {{action "save" on="submit"}}> <div class="form-group"> <label for="title">Title</label> {{ input value=model.title class="form-control"}} </div> <div class="form-group"> <label for="content">Content</label> {{ textarea value=model.content class="form-control"}} </div> <button type="submit" class="btn btn-primary">Save</button> {{#link-to 'posts.index'}}<button class="btn btn-default">Cancel</button>{{/link-to}} </form> </code></pre> This partial template will be used for our edit form as well. Here’s the how the form looks now: </a> Edit</h2> app/routes/posts/new.js</code> will handle saving and rolling back if a user decides to cancel an edit: import Ember from 'ember'; export default Ember.Route.extend({ deactivate: function() { var model = this.modelFor('posts/edit'); model.rollback(); }, actions: { save: function() { var _this = this; this.modelFor('posts/edit').save().then(function() { _this.transitionTo('posts.index'); }); } } }); </code></pre> And because we made our form a partial that is only tied to the existence of a model our app/templates/posts/edit.js</code> is as simple as this <h3>Edit Post: {{model.title}}</h3> {{ partial 'posts/form'}} </code></pre> </a> Show</h2> For when we want to view the post without editing. Thanks to Ember having awesome conventions we only need to edit the template file app/templates/posts/show.hbs</code> <h3>{{model.title}}</h3> <div>{{model.content}}</div> {{#link-to 'posts.index' classNames="btn btn-default"}}Back{{/link-to}} </code></pre> Delete</h2> Last but by no means least we need to place a delete action in our app/routes/posts/index.js</code>. How else would we delete all the test posts we’ve made? import Ember from 'ember'; export default Ember.Route.extend({ actions: { delete: function(post) { var _this = this; post.destroyRecord().then(function() { _this.transitionTo('posts.index'); }); } } }); </code></pre> Here’s a preview of our posts index with a couple of posts added: </a> What next?</h2> If you're interested in setting up authentication you can check part 3 of this series, Using Padrino with Ember: Authentication</a>. There is a lot of room for growth. Things that are often needed in SPA’s include validation, flash messages and realtime data. They are all very doable with Padrino and Ember but are beyond the scope of this article. For server-side validation take a look at the Sequel validation documentation</a>. Infact, the whole Sequel documentation is pretty awesome. I recommend adding an error attribute to RABL objects which Ember can check for. If it exists it should stop transitions and loop through all of the errors in the template. For flash messages I tend to create a mixin from the code in this article</a> which works well. For realtime data I’ve had success with Pusher</a> which has a nice free package. The Pusher gem</a> is really easy to integrate with Padrino. Summary</h2> Well there you have it. Ember CLI with a Padrino backend. All the beauty of Ruby without the all of the unnecessary parts of Rails. In these two posts we’ve covered a lot of the core functionality needed in any single page application. Creating, reading, updating and deleting data from our API and from Ember. We’ve also taken a look at what we can use when we need to do more than just simple CRUD commands. If you wish to see the full source for both of these articles you can view it on Github</a>. Using Padrino with Ember CLI Part 1 2015-02-11T00:00:00+00:00 After listening to the Ruby Rogues’ Padrino episode I was sold on the idea of using Padrino for smaller websites and simple API’s. I know Grape</a> is also a perfect contender for building an Ember APIs but: I am already familiar with Sinatra so the learning curve shouldn’t be as steep.</li> I wanted to get to know Padrino.</li> Funsies. I’m going to show you how to quickly set up both together, build a restful API compatible with Ember’s ActiveModelAdapter</code> and show you a few gotchas to help you on your way.</li> </ul> Note</h2> This article is aimed at people familiar with Ruby and have some understanding of the MVC pattern (ideally with Padrino or Rails). This article is not a guide for starting out with Padrino. If you have previous Ruby web framework experience you’ll most likely catch on quick. On the Ember side of things you should be comfortable with Javascript, Ember and ideally Ember-CLI. I will try to explain everything I do but this article is more about getting the two frameworks to work together. You can view the full source for both of these articles on Github</a>. Getting Started</h2> Make sure you have Padrino and Ember-CLI installed. With Ruby and NPM this should be a matter of gem install pardrino</code>, npm install -g ember-cli</code> and npm install -g bower</code>. See Padrino’s Installation Guide</a> and Ember CLI’s Getting Started</a> for more details. For reference I’m using the following library versions: IO.js 1.2.0 (Also tested with Node 0.10.36)</li> NPM 2.5.1</li> Ember-cli 0.1.15</li> Ember 1.8.1</li> Ember-data 1.0.0-beta.14.1</li> Bower 1.3.12</li> ruby-2.1.1</li> Padrino 0.12.4</li> </ul> For a directory structure to this article we want 3 directories. - Blog |- API |- App </code></pre> Make Blog</code> main directory and change in to it. mkdir Blog && cd Blog </code></pre> Setting up Padrino</h2> One of the features of Padrino I love the most is the ability to swap different libraries to your preference. For instance, you have the choice to use your preferred ORM. If you know Rails then you will most likely be comfortable with ActiveRecord. I have recently been dabbling with Sequel and will be using it for this tutorial as I have become quite fond of it. Run the following commands to set up Padrino padrino g project API -d sequel -t minitest cd ./API bundle </code></pre> Check the Generators</a> documentation for more options. You can specify css precompilers, Javascript libraries and mocking libraries as well. As they are not really relevant to this article I have left them off. Open up your Gemfile in API/Gemfile</code> and add the following gems: gem 'rabl' gem 'oj' gem 'rack-cors', :require => 'rack/cors' # Optional group :development do gem "better_errors" end </code></pre> RABL</a> stands for “Ruby API Builder language” and let’s us generate JSON for our API incredibly easily. I have to say, I found the documentation incredibly useful and I have found examples for every use case I’ve needed so far. Oj</a> is a RABL dependancy for “speed optimized JSON handling”. Rack/CORS</a> “provides support for Cross-Origin Resource Sharing (CORS) for Rack compatible web applications.” Better Errors</a> makes debugging so much easier. You can remove it for the tutorial but I do recommend using it in your own applications. Run bundle</code> to install the new dependancies. For the sake of keeping the article short we will be creating the API in one Padrino application but it is possible to mount multiple Padrino apps within one another. We could have one app mounted to api/v1/</code> and then, if we plan to upgrade our API, it’s as simple as mounting another app to api/v2/</code>. Take a look at the Mounting Applications</a> documentation for more information on mounting apps. Also check here</a> for generating the sub-applications. The Model</h2> Keeping things simple, we’ll have one CRUD API for managing blog posts using using the default sqlite database. We’ll make the model called Post</code> that has 5 fields, id</code>, title</code>, content</code>, created_at</code> and updated_at</code> padrino g model Post title:string content:text created_at:datetime updated_at:datetime </code></pre> This will create 3 files, your model, a migration file and a file for your model tests. Open the migration file located in db/migrate/001_create_posts.rb</code> and change the updated_at field to be nullable. Sequel.migration do up do create_table :posts do primary_key :id String :title Text :content DateTime :created_at DateTime :updated_at, null:true end end down do drop_table :posts end end </code></pre> When using Sequel you can migrate your database to the latest migration with this rake command: rake sq:migrate:up </code></pre> To make our timestamp columns behave like Ruby on Rails we need to add the Sequel timestamp plugin in our config/database.rb</code>. Sequel::Model.plugin(:timestamps) </code></pre> In the models/post.rb</code> add the following line: class Post < Sequel::Model Sequel::Model.plugin :timestamps end </code></pre> This line will sort out updating created_at</code> and updated_at</code> when necessary. The Controller</h2> Run the following to generate the controller: padrino g controller Posts get:index post:create get:show patch:update delete:destroy </code></pre> This will create our controller in app/controllers/post.rb</code>. We can see in the command we’ve deliberately left out new and edit methods from our CRUD API. This is because Ember has no need to query them (at least it won’t for our simple application). Running rake routes</code> we’ll see how we can interact with the routes. URL REQUEST PATH (:posts, :index) GET /posts (:posts, :create) POST /posts/create (:posts, :show) GET /posts/show (:posts, :update) PATCH /posts/update (:posts, :destroy) DELETE /posts/destroy </code></pre> Let’s make it so api/v1 is prepended and for familiarity we’ll also modify our routes to mirror Rail’s conventions found here</a>. In app/controllers/post.rb</code> change it to the following: Edit: Big thanks to Nathan Esquenazi</a> for showing me a much cleaner way of doing it. For reference you can see my previous code here</a> Api::App.controllers :posts, map: "api/v1/posts" do get :index, map: "" do end post :create, map: "" do end get :show, map: ":id" do end patch :update, map: ":id" do end delete :destroy, map: ":id" do end end </code></pre> If you run rake routes</code> now you should see the following: (:posts, :index) GET /api/v1/posts (:posts, :create) POST /api/v1/posts (:posts, :show) GET /api/v1/posts/:id (:posts, :update) PATCH /api/v1/posts/:id (:posts, :destroy) DELETE /api/v1/posts/:id </code></pre> Much better. Now let’s fill in the details require 'json' Api::App.controllers :posts, map: "api/v1/posts" do get :index, map: "" do @posts = Post.all render "posts/index" end post :create, map: "" do parameters = post_params if parameters["post"].nil? return '{}' end @post = Post.create parameters["post"] render "posts/show" end get :show, map: ":id" do @post = Post[params[:id]] render "posts/show" end put :update, map: ":id" do @post = Post[params[:id]] if @post.nil? return '{}' end parameters = post_params @post.update parameters["post"] render "posts/show" end delete :destroy, map: ":id" do @post = Post[params[:id]] @post.delete unless @post.nil? end end def post_params JSON.parse(request.body.read) end </code></pre> If you're familiar with Active Record you should see some familiar method names. all</code>, create</code>, delete</code> and update</code> are self explanatory. You may be unfamiliar with how Sequel finds specific rows, though. Post[params[:id]]</code> is the simplest way to retrieve a record by primary key. params[:id]</code> is just the URL id parameter. So it's more like calling Post[1]</code>. Occasionally we return blank objects with return '{}' </code></pre> This may seem unneeded but Ember expects a valid JSON response and if it doesn't get one it will throw a hissy fit. Views</h3> Now we’ll get the JSON responses working. Sequel and RABL make this nice and easy. Create these two files: app/views/index.rabl</h3> collection @posts, root: "posts", object_root: false attributes :id, :title, :content, :created_at, :updated_at </code></pre> app/views/show.rabl</h3> object @post attributes :id, :title, :content, :created_at, :updated_at </code></pre> If you’ve never used RABL before this may look quite alien to you. We use the collection</code> method when working with multiple objects and the object</code> method when specifying one object in particular. The collection method has two parameters, root</code> and object_root</code>. root</code> specifies the parent key that wraps around the collection. We set object_root</code> to false because by default RABL adds another key around each row. Essentially we are changing this JSON: [{ "post": { "id":1, "title":"test", "content":"test", "created_at":"2015-02-11 20:25:21 +0000", "updated_at":null } }] </code></pre> To this Ember-friendly JSON { "posts": [{ "id”:1, ”title":"test", "content":"test", "created_at":"2015-02-11 20:25:21 +0000", "updated_at":null }] } </code></pre> Lastly, the attributes</code> method lets us choose which data we want to show in our API. A word on CSRF Protection</h3> The problem</h4> With Rails and Ember-Rails it’s possible to set up CSRF protection by having an API end-point that provides the CSRF token. That token is then placed in a meta tag called csrf_token</code> and then with Ember you set up an AJAX preFilter which sends the token in a header named X-CSRF-Token</code>. All this is possible with Padrino’s csrf_token</code> method, but due to the fact that your API and Ember-CLI are separate applications you will not have access to the session which verifies the token. The solution</h4> You have 2 options. Disable CSRF entirely or, if your Padrino app is more than just an API, disable it for your API. Disabling CSRF Entirely</h4> Go to app/config/apps.rb</code> and set the following set :protect_from_csrf, false </code></pre> If your app is currently running make sure you restart it now with bundle exec padrino start</code>. Disabling CSRF for your API</h4> If you’re using Better Errors, go to app/config/apps.rb</code> and set the following set :protect_from_csrf, except: %r{/__better_errors/\\w+/\\w+\\z} if Padrino.env == :development </code></pre> If your app is currently running make sure you restart it now with bundle exec padrino start</code>. In app/controllers/posts.rb</code> we need to disable CSRF for any requests that aren’t get</code>. We can do that by setting csrf_protection: false</code> in the parameters. require 'json' Api::App.controllers :posts, map: "api/v1/posts" do get :index, map: "" do @posts = Post.all render "posts/index" end post :create, map: "", csrf_protection: false do parameters = JSON.parse(request.body.read) if parameters["post"].nil? return '{}' end @post = Post.create parameters["post"] render "posts/show" end get :show, map: ":id" do @post = Post[params[:id]] render "posts/show" end put :update, map: ":id", csrf_protection: false do @post.update params render "posts/show" end delete :destroy, map: ":id", csrf_protection: false do @post = Post[params[:id]] @post.delete unless @post.nil? end end </code></pre> CORS</h3> We will be using Ember-CLI’s proxy option so we don’t have to worry about CORS. However for production you may want to include it. In app/app.rb</code> Add the following lines of code to your App</code> class use Rack::Cors do allow do origins '*' resource '*', :headers => :any, :methods => [:get, :post, :options, :delete, :patch] end end </code></pre> If you look at the Rack/CORS documentation, you can specify URLs that are allowed to access your API by updating the origins method. origins 'localhost:4200' # Ember CLI App </code></pre> Before moving on to Part 2 make sure your Padrino app is up and running. Use bundle exec padrino start</code>. Summary</h3> That’s it for part 1. We’ve successfully made an API compatible with Ember’s ActiveModelAdapter. We’ve disabled CSRF where necessary and enabled CORS. Click here to view part 2 for implementing the Ember side of the project</a>.

Failed</h3>
</p>

Views</h3>
Now we’ll get the JSON responses working. Sequel and RABL make this nice and easy.</p>
Create these two files:</p>

`Summary</h3> That’s it for part 1. We’ve successfully made an API compatible with Ember’s ActiveModelAdapter. We’ve disabled CSRF where necessary and enabled CORS.</p> Click here to view part 2 for implementing the Ember side of the project</a>.</p>`

- SQLite

Using Padrino with Ember CLI Part 5: Realtime

Using Padrino with Ember CLI Part 4: Authorisation

Using Padrino with Ember CLI Part 3: Authentication

Using Padrino with Ember CLI Part 2

Using Padrino with Ember CLI Part 1

- SQLite

Using Padrino with Ember CLI Part 5: Realtime

Using Padrino with Ember CLI Part 4: Authorisation

Padrino</h2> I want to mention a sweet tip when working with APIs in Ruby.</p>

Tidying up Ember</h2> At this point our authorisation is in place but it's hardly a good idea to leave all those buttons for adding, editing and deleting data lying around.</p> Let's change app/templates/posts/index.hbs</code> to hide these buttons when the user's aren't logged in.</p>

Using Padrino with Ember CLI Part 3: Authentication

Failed</h3> </p>

Using Padrino with Ember CLI Part 2

Routes</h3> In app/router.js</code> add the following routes:</p>

Index</h2> Let’s update the posts index template in app/templates/posts/index.hbs</code> to iterate over the posts:</p>

Delete</h2> Last but by no means least we need to place a delete action in our app/routes/posts/index.js</code>. How else would we delete all the test posts we’ve made?</p>

Using Padrino with Ember CLI Part 1

Views</h3> Now we’ll get the JSON responses working. Sequel and RABL make this nice and easy.</p> Create these two files:</p>

Summary</h3> That’s it for part 1. We’ve successfully made an API compatible with Ember’s ActiveModelAdapter. We’ve disabled CSRF where necessary and enabled CORS.</p> Click here to view part 2 for implementing the Ember side of the project</a>.</p>

Failed</h3>
</p>

Views</h3>
Now we’ll get the JSON responses working. Sequel and RABL make this nice and easy.</p>
Create these two files:</p>

`Summary</h3> That’s it for part 1. We’ve successfully made an API compatible with Ember’s ActiveModelAdapter. We’ve disabled CSRF where necessary and enabled CORS.</p> Click here to view part 2 for implementing the Ember side of the project</a>.</p>`