kjg
commented
8 years ago I think it would make sense to have a header that specifies the path originally used to sign the request. On the server side I wonder if we should provide for some sort or warning or ability to pass allowed paths into the authentic? method or some other way to make this an opt in only feature
On February 3, 2016 at 8:19:59 AM, elliot nelson (notifications@github.com) wrote:
It might be nice to have some facility to provide rewrite rules in a configuration block. For example, if you have some Rack rewrite (or nginx/unicorn-level rewrites), it's difficult to get a signature match.
As an example, if the incoming request_uri is /api/v1/posts, it'd be nice to be able to say:
ApiAuth.allow_uri('api/v1/posts', ['api/posts', 'posts'])
(The desired outcome is that if I POST to /posts, and nginx rewrites my request to /api/v1/posts, ApiAuth will check each possible signature and return true if any of them match.)
(Another approach might be an option allowing you to specify a certain header -- Http-X-Original-URI, for example, or whatever header your web server might generate -- instead of using request_uri when building and verifying the signature.)
— Reply to this email directly or view it on GitHub https://github.com/mgomes/api_auth/issues/95.
iMacTia
PaulaCara
It might be nice to have some facility to provide rewrite rules in a configuration block. For example, if you have some Rack rewrite (or nginx/unicorn-level rewrites), it's difficult to get a signature match.
As an example, if the incoming
request_uriis/api/v1/posts, it'd be nice to be able to say:(The desired outcome is that if I POST to
/posts, and nginx rewrites my request to/api/v1/posts, ApiAuth will check each possible signature and return true if any of them match.)(Another approach might be an option allowing you to specify a certain header -- Http-X-Original-URI, for example, or whatever header your web server might generate -- instead of using
request_uriwhen building and verifying the signature.)