Can't the mod_rewrite in Apache set an environment variable with the original request? [E=ORIG_PATH:$1]
Or set a header if proxying the request after rewrite (similar to X-Forwarded-For or X-Forwarded-Proto) to preserve the original request path? ----- Everyone's main interest, I'm guessing, in OAuth 2 and MAC is in protecting REST APIs. It would be weird for MAC to treat HTTP as a transport protocol like SOAP. If you keep it closer to HTTP, maybe we'll eventually have modules created for verifying the signature of MAC signed requests just in the web server without dealing with the backend web framework. How cool would it be just to have a nginx module to verify the signature using the secret looked up via something like the HttpRedis or Drizzle modules. On Apr 18, 2011, at 12:40 PM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Justin Richer [mailto:[email protected]] >> Sent: Monday, April 18, 2011 12:35 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] MAC request URI normalization (query >> parameters) >> >> Any instance of apache's mod_rewrite will bork up the request URL for >> anything behind the rewrite. The server or client code behind a rewrite will >> only see the rewritten URL and not the original request URL. > > That's true for any normalization so not a valid issue (for this particular > question). > >> Why not just pack the signed string in with the payload? You would then >> have rules on verification instead of normalization. The client gets to sign >> the >> raw URL (or whatever bits, really) however it wants to, and the server can >> decide if the signed bits adequately cover the full query or not. > > Any duplication of HTTP request bits for the purpose of signatures (or MAC) > is a really bad idea (tm). This is my main objection to the JWT family of > proposals in which HTTP request components are duplicated in each request. > Why use any HTTP components at all? Just use one URI with GET for all your > API needs and define an internal signed structure for the request... If you > do that, you are basically moving away from REST and into SOAP. To me, this > is a very clear line - absolutely no duplication what-so-ever. > > EHL > >> -- Justin >> >> On Mon, 2011-04-18 at 15:26 -0400, Eran Hammer-Lahav wrote: >>> I would like to drop all the request URI parameters normalization >>> logic and just use the raw request URI instead. A year ago during the >>> discussion on my Token authentication scheme (which had that behavior >>> specified), some people raised the issue that access to the raw >>> request URI isn’t always possible on the client or server. This feels >>> like a limitation that is no longer a real problem for any modern web >>> development environment. >>> >>> >>> >>> If you know of actual deployment issues with using the raw request URI >>> instead of the parameter parsing and sorting voodoo, please let me >>> know. Otherwise, the next draft will drop that entire section. >>> >>> >>> >>> EHL >>> >>> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
