Invoke-RestMethod does not strip Authorization Headers #2227
Comments
|
This may be related, otherwise I can open a separate issue. On PowerShell Core, on both Nano Server and Linux: [Nano - GA Release - PowerShell Core] Major Minor Build Revision
----- ----- ----- --------
5 1 14393 1000 [Linux - PowerShell Core (alpha.11] Major Minor Patch Label
----- ----- ----- -----
6 0 0 alphaAuthorization header format should follow: If my Authorization header includes commas, in specific cases, Invoke-WebRequest / Invoke-RestMethod will give a syntax error but do not get this error when on Windows PowerShell. # Fails
$Headers = @{}
$Headers.Add('Authorization', "AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, SignedHeaders=host;range;x-amz-date, Signature=fe5f80f77d5fa3beca038a248ff0
27d0445342fe2855ddc963176630326f1024")
Invoke-WebRequest -Uri www.google.com -Headers $Headers# Success
$Headers = @{}
$Headers.Add('Authorization', "AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request SignedHeaders=host;range;x-amz-date, Signature=fe5f80f77d5fa3beca038a248ff0
27d0445342fe2855ddc963176630326f1024")
Invoke-WebRequest -Uri www.google.com -Headers $HeadersAll I do is remove a single comma after the Credential=VALUE portion, and it passes? Works either way on normal Windows PowerShell. Note: Example pulled from http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html Workaround: |
|
@ScriptAutomate you should open that as a separate issue @dave-tucker I invested this and it seems to be an issue with AppVeyor's REST API (or potentially libcurl). In anycase, if you don't specify the Authorization header, it succeeds. If you specify the Authorization header with curl, it similarly fails. I created a PR to fix their sample appveyor/website#255 |
|
Looks like the problem is with libcurl which .Net Core depends on. The Auth header is needed by AppVeyor and after auth, they redirect to the Azure Blob Storage which doesn't need it, but because it's there tries to validate and fails. I'll follow-up with libcurl. |
|
It doesn't look like libcurl is going to change this behavior. We can handle the 302 redirect in the cmdlets and remove the Auth header by default (make it consistent with Windows) and add a switch to include it on redirect if desired |
|
Perhaps by default, if the redirect is to same domain, we preserve the headers; if to different domain, we clear them. Also expose -ClearHeadersOnRedirect switch |
|
I recommend a less intrusive fix. Add a -ClearAuthorizationOnRedirect and strip the authorization header on the first redirect. This means we only handle the first redirect and allow the lower level to handle any subsequent redirects. |
|
@PowerShell/powershell-committee should review:
|
|
Per @PowerShell/powershell-committee conversation:
|
|
Based on the comments from the committee; I'm going to change the current implementation to default to the behavior and also provide a PreserveAuthorizationOnRedirect to handle edge cases. The reason for the change is as follows: The PreserveAuthorizationOnRedirect will disable this logic for the request for edge cases where the redirected request needs to include the authorization header. NOTE: There are various discussions floating around about the reverse problem; the header is stripped and callers must handle redirects manually in code. The switch is intended to address this use case when the cmdlet is used. |
|
I think this needs to be merged into the PowerShell master branch before we can close or resolve it. |
… Invoke-RestMethod to address fix for PowerShell/PowerShell#2227
Invoke-WebRequest and Invoke-RestMethod cmdlets will now strip authorization header on redirect unless the new parameter `-PreserveAuthorizationOnRedirect` is specified. The FullCLR implementation uses WebRequest to perform the request which silently strips the Authorization header when a redirect occurs. The CoreCLR implementation uses HttpClient to perform the request which does not strip the authorization header. The change explicitly handles the initial redirect, removes the authorization header and submits the request to location in the response. Fixes #2227
Steps to reproduce
Attempt to download something using
Invoke-RestMethodthat requires anAuthorizationheader AND generates a 302 redirect to the final location of that resource.One such example is downloading a build artifact from an AppVeyor project.
E.g from the example here
Expected behavior
The request should succeed like it does on Windows
Actual behavior
The request fails with the following error
Having debugged this with AppVeyor support it seems they send a 302 redirect to a location in Azure. On Windows, I've verified with Fiddler that the
Authorizationheader is stripped which allows this command to succeed. On Mac it would appear theAuthorizationheader is not stripped, causing Azure to generate the error.Environment data
The text was updated successfully, but these errors were encountered: