These could be solved and the whole normalization process thrown out by
just restating the string that you signed. It's then up to the server to
decide if they want to reparse and validate the request or not, but it
gets around url rewriter problems, which I've had definite trouble with
in my deplo
I think it's perfectly reasonably - if inside the service you need to
rewrite the URI, it's not hard to preserve the original as an extra
header or ENV.
We have a HMAC-sha1 implementation in production where the load
balancer (nginx) may rewrite the URI before passing it to a java app
that authent
sage-
>> From: Justin Richer [mailto:jric...@mitre.org]
>> 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&#x
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> 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
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.
Why not just pack the signed string in with the payload? You would then
have rules on veri
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 p
