Yeah it was a little tricky. At this level we don't have access to the actual request object--in this file we are declaratively defining in the routes, and all of this happens during setup, before an actual request comes in. The middleware function is invoked for every request, and so that's where we have access to the actual request object.  A couple of other approaches I considered were to pass in an object literal instead of a string, so it would look more like this:
````
auth.verifyPoetAccess({ poetField: 'id' })
````
adding a bit of documentation to the caller. Felt a little weird, but I'm not opposed to it. It's pretty much what passport does for the usernameField and passwordField properties. 

Another approach considered was to have different methods for GET and for POST, and assuming the field name in each of those:
````
auth.verifyPoetGet()   // assumes req.params.id
auth.verifyPoetPost()  // assumes req.body.poetId
````
but then if the get parameter is called something other than 'id', or the post parameter is called something other than 'poetId' in some other scenario, we're right back to where we started. 

I initially started with the inline imperative approach, calling the isPoetInPoem method directly from  but a few smells led me down the middleware route. It felt like I was mixing security and application concerns, and middleware provided a nice way to keep those concerns separate. It also added yet another level to the callback chain. I went back and forth with this.. had it implemented both ways a couple times.

Any other way you can think of to make the middleware interface cleaner?