Added a convenience function to pull a desired claim value out of the token

[ChrisWhiten]

Added a method to the API that will retrieve a given claim from the payload, and return its value to the caller. This is especially useful if the JWT token contains information that can assist Nginx with tasks such as message routing.

Example usage in nginx.conf

local jwt = require("nginx-jwt")
jwt.auth()
local sub = jwt.get_claim("sub") -- retrieve the value from the "sub" claim
ngx.say("Sub: ", sub)

[twistedstream]

@ChrisWhiten sorry for taking so long to get back to this.

Can you explain a little more the use case that requires this convenience function? I ask because the existing auth function already provides a way to ensure certain claims exist with desired values. So if that's all you're wanting to do, then I'd suggest we stick with (or enhance if needed) the auth function.

But if you've got something else in mind, I'd love to understand the details.

[ChrisWhiten]

Thanks for getting back to me @twistedstream

The use case here is a bit different than just deciding whether a claim exists or not. The use case I was targeting is more pulling out the value of a given claim, so that we can use that later on. For example, imagine a scenario where you are routing requests from a specific customer to a specific server. You can have a customer_id claim, and we want to pull out that value to do a database lookup to route an incoming request to the right server.

At a high level, that was a use case that wasn't clearly satisfied with the library as it stands, and that's why I added that convenience method - to return the value associated with a claim, rather than just whether or not that claim exists with a specific value

[twistedstream]

@ChrisWhiten: Ah, good. So this routing logic would still be running in the nginx server (presumably in some calling Lua code in the nginx.conf). Your use case makes a lot of sense.

The only thing I'd change with your implementation is to maybe not repeat the use of the same regex parsing of the Authorization header. Do you think you could pull that logic into a shared private function and refactor the auth function to use it?

[twistedstream]

Ideally we'd also have a test or two to verify the new function works and continues to work.

[ChrisWhiten]

@twistedstream Sure, I can do that shortly. As a heads up, the test setup doesn't seem to work on OS X, since all of the Docker scaffolding scripts appear to fail.

[twistedstream]

@ChrisWhiten Have you installed Docker Toolbox? We moved away from using boot2docker as of PR #36

[ChrisWhiten]

@twistedstream Sorry for the delay on this - it fell through the cracks on me. As requested, I've refactored out the regex parsing and added a couple of tests to verify that the new functionality doesn't break going forwards