Authorization and Authentication in a Rails API
When creating an API in Rails your authentication (and to some extent authorization) techniques will vary somewhat based on your API’s purpose.
This article is part of a series on writing APIs in Rails. You can refer back to the original article for a list of the different types of APIs, links to other articles in the series, and background information.
Creating APIs Using Rails
With the advent of increasing numbers of single page and mobile applications developers are now more likely to use Rails to implement a resource-oriented API in place of more traditional HTML page-oriented applications.
There are quite a few issues and decisions that need to be made while implementing an API in Rails. This article is the first in a series where I’ll describe the technologies used in Rails APIs and the issues that need to be considered while developing one. In future articles I’ll cover each issue in more detail.
Creating Rails Admin Pages from Scratch (Part 1: Index)
Previously I wrote about some problems I’ve been having using the common Rails admin gems. This is the second article I’ll be writing as part of a series where I’ll be examining how easy it is to create most of the functionality of these gems from scratch with the help of a few smaller, single-purpose gems.
Last time I wrote about
how we could simply use the
Rails scaffold generator
to create our admin pages.
Eventually we’ll find that approach
to be somewhat limited.
Instead what we’ll do
is create our own base admin controller and views
and use those to build pages for an existing model
(the Admin user account model from the previous post).
There’s a fair amount of work needed to implement the different
request types so this article will only cover the index action.
Rails Scaffold's Dangerous Defaults
A big attraction to Rails is how quickly you can set up a database-backed web application with a decent amount of functionality. The Rails generators are a big help to initialize components and construct a scaffold of all the things you need to make a resource: models, migrations, controllers, views, routes, and even tests.
While the scaffold generator can help build wide swaths of an application, you do need to pay some attention to what it’s doing for you. One thing that might surprise developers is how accommodating the default scaffold is in replying to requests for different data formats.
In this article I’ll look at how blindly using the Rails scaffold generator (version 4.2 as I write this) can inadvertently expose data you might otherwise have thought was secret to your application.
Building Admin From the Rails Scaffold
Previously I wrote about some problems I’ve been having using the common Rails admin gems. This is the first article I’ll be writing as part of a series where I’ll be examining just how hard it really is to create most of the functionality of these gems from scratch (with the help of a few smaller, single-purpose gems).
In this article we’ll set up a new example application (it’s the classic blog example) and create the basic CRUD (create/read/update/delete) functionality for our admins. We’ll also set up basic admin user accounts to control access to our data.
Get Rid of Your Admin Gem
After using the two most popular Rails admin gems ActiveAdmin and RailsAdmin I have been increasingly disillusioned with their overall utility. While they both provide a quick way to put up a pretty interface to the various models in your system, they also come with their own baggage: application bloat and inflexibility amongst them. Eventually you may find it necessary to modify their configurations and inner workings to the point where it might have been easier to just build things from scratch in the first place.
In this post I’ll look at some of the basics of these two popular gems and some of the drawbacks I’ve encountered using them. In subsequent articles I’ll explore what it takes to build your own admin interface providing admin users on your site the controls necessary to make changes to the system to keep their users happy.
Never Check for an Error You Don't Know How to Handle
I used to work with a curmudgeon developer who was known to say “never check for an error you don’t know how to handle”. Since this was back in my C programming days it was meant as a joke (I hope). At that time we didn’t have exceptions. Any library or system call you made could return a myriad of errors, not all of which were obvious or expected. Yet you still had to think about all the possible error eventualities if you ever hoped to have a robust application.
Recently I’ve worked on a couple of Rails applications where previous developers sprinkled their code (mostly controllers) with lots of generic rescue statements. It turns out this didn’t make these applications more robust. Instead, the exception handling masked real problems in production.
Given that any good framework we use today has some sort of reasonable default exception handler, we shouldn’t be trying to rescue unexpected exceptions. Without getting into whether certain framework methods should raise an exception or not we’ll examine the problems presented by overly aggressive error handling and see why given our current languages, frameworks, and monitoring tools it probably is correct to “never check for an error we don’t know how to handle”
Getting Strapped Down by Bootstrap
Twitter’s Bootstrap is a CSS styling framework that can easily be dropped into a web application providing a nice look and responsive design out of the box. For developers that are design-challenged like myself, tools like this provide a very nice polish over the browser’s default settings.
While the framework is easy to implement it encourages a coding style for the HTML in your application that makes your code less maintainable and goes against many best practices that you probably use throughout the rest of your code. The biggest part of the problem is the prescribed class names that you have to put in your HTML to define how you’d like your page to be styled.
Cleaning Up Rails 4 Production Logging
I’ve seen some very effective use of application logging to debug difficult problems. The foundation of good logging is being sure that your application is logging the right things. However, it’s just as important for your log files to be easy to parse - both for a human reading the file and for any scripts that might be written to extract information from them.
While Rails' conventions allow you to easily write powerful web applications the default logging available comes up short on both capturing critical information and providing it in a consumable fashion. This can be expected since Rails itself is just a framework and thus the logging available out of the box is really only about the framework itself. Left unmodified, the default logging can be a bit surprising the first time you go to look at a production problem.
I’ll be describing how to start taming your production logs to make them useful and ready to scale along with you application. I’ll show you how to turn several lines of rambling output per request into one concise line with the essential information that needed to debugging production problems. This will be the basis for adding logging specific to your business logic and future debugging requirements.
Rails ActiveRecord Serialize
First off I have to admit I am not the best Googler in the world. So when I set out to figure out how to store a bunch of key/value pairs into a single text column in a database it is somewhat understandable that I turned up confusing results around Rails serialize. Unfortunately it looks like they’ve somewhat overloaded the “serialize” concept in Rails. The root of the term refers to both:
- The notion of marshaling your data into a string of text and storing it in a column in the database.
- Creating data for a rails API (often to be used with a JavaScript framework) from a model.
My use case is storing a bunch of key/value data that I don’t necessarily control the source of. I may want to add data for new keys or have older keys' data be deprecated. Also, I likely won’t need to query on any of the data so one of the best solutions would be to encode the data into some kind of text format and store it as a text column on an appropriately associated model. I’m using MySQL and thus don’t have the capabilities of a nosql or schema-less database at my disposal.