rob
/
old-techblog
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add rack-filter-param post

This commit is contained in:
Rob Watson 2018-01-18 06:54:06 +00:00
parent fdbbc5e4c5
commit 05aef5fe9d
1 changed files with 34 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
_posts/2018-01-18-rack-filter-param.md Normal file
View File

@ -0,0 +1,34 @@
---
layout: post
title: "2017 roundup part 2: rack-filter-param"
slug: rack-filter-param
date: 2018-01-18 06:00:00 +0000
categories: ruby gems foss rack
---
Hot on the heels of [thes](/blog/2018/01/16/thes-gem/) is another Ruby gem: this time containing some [Rack](https://rack.github.io/) middleware.
[rack-filter-param](https://github.com/rfwatson/rack-filter-param/) solves a simple problem. As the name suggests, it allows HTTP parameters to be filtered from incoming requests based on arbitrary application logic.
The middleware needs only the most minimal configuration. For example, here it is being configured to strip the `client_id` parameter from incoming requests, based on some assumed application-level logic:
```ruby
use Rack::FilterParam, {
param: :client_id,
if: -> (value) { should_I_do_it?(value) }
}
```
When the application method `should_I_do_it?` returns a truthy value, the `client_id` parameter is stripped from the request, which is then passed upstream.
It is a library born of a real-world refactoring problem. A legacy authentication library, that had been part of Mixlr's API, was being replaced with a newer library. While doing so it was discovered that a particular HTTP querystring parameter, hard-coded into numerous client apps, triggered some unwanted and buggy behaviour in the new library.
Fixing the problem by pushing out updates to the client apps, and removing the parameter completely, wasn't an option. That would have left the app broken for all users who didn't or couldn't update to the new version. And patching the new library felt wrong too, because it would only increase future maintenance burden and make it more difficult to keep the library up-to-date.
The next step was to attempt to remove the parameter using Nginx, but the unwanted behaviour was only triggered when the parameter had certain values. In other words, the removal of the parameter depended on application logic, and application logic belongs in the application and not hidden in the front-end web server configuration.
So the correct solution appeared to be to manipulate the request at the Rack middleware layer, which is part of the application but kicks in early enough to be able to remove the parameter in good time. And extracting it as a gem kept the application itself clean of legacy code paths, and allowed it to be re-used by anybody in the future.
You can read more and browse the source code over on my GitHub page.
[https://github.com/rfwatson/rack-filter-param](https://github.com/rfwatson/rack-filter-param)