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.
I’ve been building a trial version of our production environment, hosted on AWS. I’m using debian as it’s what I’m most familiar with, and I’ve chosen to use puma to serve the rails end of the site.
Puma comes with an init.d script, and a control process called pumactl. These were non-trivial to get working, particularly when also using rvm, so I thought I’d document what I did in case someone else wants to do the same. The script uses great terminology based around the puma theme, so we have a jungle of pumas which may or may not come out to play. In essence you can have multiple puma instances on your server, each serving a different application.
I’ve been working on creating a sample infrastructure on Amazon. I’m choosing to use the Debian AMI, mostly because all my servers for a number of years have been Debian, and I’m familiar with it. I wanted to install the logcheck package so I could get notifications, and in turn I wanted those messages to be mailed to me on my home mail address so I could review them.
Mail on AWS is sent using Amazon SES. There are instructions in the Amazon documentation for configuring exim, and I found different instructions around the net, but in general they resulted in all local mail also being delivered via SES. This is a problem for me as I haven’t configured any mail receipt for this domain, so lots of mail went into the aether, as well as being generally inefficient to send local mail out via SES. Finally, some of the configurations appeared to be pushing usernames and passwords into the exim config file, which I didn’t like much.
I managed to navigate my way to a more standard exim4 configuration that works, this documents how to achieve that.
I’ve been interested for a while in getting underfloor heating, probably of the hydronic variety. Underfloor heating offers some benefits in terms of less air movement and noise, and of giving a more liveable ambient heat – there is some evidence that the warmth of your feet is a key determinant of how comfortable your house is in winter.
The concept has been to use a large water storage tank as thermal mass, and to use evacuated tube water heating to heat that tank. This gives most of the benefit of having large thermal mass in your house, whilst giving control over when you take the heat out of that thermal mass.
This blog post explains why I think that’s probably not a great idea anymore, and what I’m thinking instead.
In this portion of the tutorial we’re going to extend to the teams entity, and build the links between clubs and teams. This means passing parameters to our list controller, and dealing with optionality. We’ll let people create a team from within the context of a club – in which case we auto-populate the club, and we’ll let them create a team standalone and pick the club from a drop-down.
This tutorial mainly consolidates what we’ve already done, but it lays the groundwork for some more interesting functionality later, including user authentication and an editable grid.
If you’ve dropped into the middle of the tutorial, you can find the code for the previous section at github: PaulL : tutorial_8. You can go to the index page for this tutorial, or you can hit the tutorial menu above and see all the posts in the Rails 4 tutorial.
I’ve been working on making an editable ngGrid, allowing users to directly edit the grid rather than going to a detail page. I’m seeing that there are two modes of operation – for simple things (maybe changing the status of a bunch of items), it’s easier to interact with the grid directly. When you want to edit a full item, you’d do this in the detail page.
The aim is to have a grid that you can edit directly, and have it save to the server when you leave the cell you’re editing (this is a reason you wouldn’t want to edit the whole record this way – you’ll end up with lots of spurious saves if the user has lots of cells to edit).
We use protractor for our end-to-end tests. A variety of pages are suggesting that selection of dropdowns, and validation of dropdowns, is tricky. And I think they’re right.
This post deals with a couple of code snippets that I’m using to deal with dropdown selection.