I’ve been working further on my application, and run into a few challenges and issues with CSRF, so I’m elaborating a bit on my earlier post. At some point my tutorials will be updated to deal with this, but for now this is a place holder that describes what CSRF protection does, where the issues lie, and what resolutions I’ve found to the overall problem.
Firstly, it seems that there are two general developer classes with Rails – those who are developing a Rails web application and therefore use Rails to create the pages, and those who are building an API using Rails, and seem to turn off CSRF protection and use an API key to authenticate (in a sense I see an API key as a long-lived username and password, so I’m not a big fan for applications that require strong security).
I’m living in a middle space – the application front-end is all AngularJS, and it’s calling Rails asynchronously using JSON. But I’m still aiming to use Devise as my authentication engine, and I want to use CSRF to protect against malicious scripts that manipulate the API without the user knowing it. The default configurations don’t really appear to deal with this situation well.
In discussing the solution, I’ll start with a simplified discussion of what CSRF protection should and shouldn’t do, and then what pieces are needed to integrate (reasonably) cleanly.
Part 8 of the tutorial focuses on adding a delete button to our ngGrid, and adding error handling in case our rails application rejects our updates. You can find the tutoral index, or hit the tutorials menu at the top and select the Rails 4 tutorial.
Part 7, in which we create karma unit tests for the list and edit controllers, including mocking the http calls.
If you’ve jumped into the middle of this tutorial, you’ll need the code from github:PaulL:tutorial_6, or you might want to visit the index page or hit the tutorials link above and look in the rails 4 tutorial.
In this, the sixth post in the rails 4 tutorial, we change our clubs list page to use ngGrid instead of our home-made table. We also implement an edit page for our clubs. A key difference from the rails 3 version of this tutorial is that we’re implementing our edit page as a page rather than a modal dialog.
If you have dropped into the middle of the tutorial you can find the code from the previous step in this tutorial at github:PaulL:tutorial_5, or you can find those tutorial pages either from the index page, or by hitting the tutorials menu in the menu bar above.
Part 5 of our tutorial, in this section we implement end-to-end testing using protractor and astrolabe to create modularised tests.
If you have dropped into the middle of the tutorial you can find the code from the previous step in this tutorial at github:PaulL:tutorial_4, or you can find those tutorial pages either from the index page, or by hitting the tutorials menu in the menu bar above.
In this post we start building out our AngularJS client, using ngResource to pull data from our rails 4 server. At the end of section 4 we should have a basic clubs list function operational.
In this post, I’m going to talk a bit more about what angular is actually doing, and how it connects to rails. Hopefully it will be semi-understandable, but I’ll note that it’s taken me a few weeks to bend my brain around what angular is doing – it’s quite different than rails.
If you’ve dropped into the middle of this tutorial, you can get the code for part 3 of the tutorial from gitHub:PaulL. If you’re looking for the other parts of this tutorial you can find them by going to the index page or hitting the tutorials menu above.
Note before you begin this section of the tutorial that ng-boilerplate is close to version 4.0, and that version will change the structure substantially. I’m planning to plug that content in over the next few weeks as it comes available, so expect this tutorial to be evolving. It should be fit for use, but if you complete it over multiple days you may find that it changes under you whilst you’re doing it. Caveat emptor.