EDIT - 4 Jan 2015
IFTTT finally began using Ruby on Rail's built-in CSRF protections sometime around November 2014. I wasn't paying any attention to this and had lost track of this blog post, so my apologies to everyone who responded hoping for a solution. I had no idea that there were many people making use of this post.
Because of the nature of CSRF protection there have to be some changes to how we proceed as we will have to retrieve a CSRF token from the server that will be sent as a header with later GET and PUT calls after authentication.
So, the following command should be run first off which will establish a session cookie and will output the CSRF token that we'll be using in subsequent calls:
curl "https://ifttt.com/login" -b ifttt.cookies -c ifttt.cookies | grep csrf
This will generate the cookie file and will tell us the CSRF token and the name of the parameter that will be expected to be sent with the login POST. I've updated the JSON object below with an example, but you'll have to update it with the value returned when you run the command. At this point you've probably already realized that it's not going to be as easy as it was to just issue a POST to log in and then keep everything going. You'll probably want to use these commands as a guide as you program your own uses using scripting languages of one sort or another to store the CSRF token for subsequent use.
The other change that you'll note in the other requests below the the inclusion of a new header, X-CSRF-Token, which is the same token given to us on this first request. It will need to be present to have any interaction with the IFTTT webserver.
IFTTT.com is a fantastic site. It is a simple automation engine based on many commonly used Internet applications and has a number of really cool applications. However, it also has a number of shortcomings: you can't AND or OR triggers together, and you can't control one recipe from another.
