Section 4.1.1. Authorization Request states:
The client constructs the request URI by adding the following
parameters to the query component of the authorization endpoint URI
using the application/x-www-form-urlencoded format, per Appendix B:
The use of the Content:Type x-www-form-urlencoded forces the request parameters to be sent in the body and not the query header. However, when submitted this way the authorization server returns an error indicating it cannot locate the client_id.
Is there a setting I need to change to support the request in the body rather than in the header?
Related
The site I am trying to scrape has a authorization header in the post request that happens to changes with each request API request for all of it's APIs. This makes my request get denied if the value of this is incorrect.
The Header Request Format:
"Authorization: WEB 2424:UmXRI7ploIWgwp4pxnzyh0EZA5Y="
Where would I get this value from?
Note: There is also a token header which you get when you login but the login itself also requires a authorization header.
IntelliJ has an HTTP client. When composing a file that is interpreted by the HTTP client, you can specify headers that go out to the server with the request, like so:
###
GET https://{{hostname}}/{{path}}
Content-Type: application/json
X-Auth-Token: {{x-token}}
I want to find the actual value of the token that was used to replace the variable name, seen above as {{x-token}}, but I don't see any way to obtain the request headers. The response headers are obviously available, but not the request headers. See the image below for the test results that are shown after running the HTTP client inside Intellij:
Is there a way to display the REQUEST headers?
Link to IntelliJ Documentation - HTTP Client -- the documentation seems to never mention the actual request headers that are sent over the wire, but they do discuss how to define request headers in composing the .http file type.
Check the Tools | HTTP Client | 'Show HHTP Requests History' action.
I followed the Sonos docs for adding app authentication and the page for using authentication tokens and the result is that the SMAPI server correctly returns an authToken together with a privateKey back to the controller. I can see the authToken being present in the credentials header inside the SOAP messages sent to my SMAPI server.
However, despite the many mentions of this inside the Sonos docs pages related to HTTP requests (I will list the resources links down below), the same authToken is not being sent inside the HTTP header Authorization, this making my CQ server unable to validate requester identity.
I tried the following, without success:
checking "Requires authorization header" capability in the customsd page of my Sonos device (I tried this because the docs page about capabilities precisely indicates that checking this "Sends OAuth token in the HTTP Authorization header.")
identifying some correlation between the "X-Sonos-" prefix HTTP headers used when the controller sends SOAP messages to my SMAPI server and the "X-Sonos-" prefix HTTP headers used when the device sends HTTP requests to my CQ server (eventually, I could not find any information that would identify the user based on this)
From Sonos device:
X-Sonos-Playback-Id: RINCON_48??????D201400:3165321802 <= deviceId inserted after RINCON_
X-Sonos-Device-Id: Sonos_U????????????????????????6 <= householdId
X-Sonos-Corr-Id: 267e3e0c-75ca-4b9d-8be4-b8a795a462a3 <= unique each time
From macOS Controller:
X-Sonos-Controller-ID: 68:??:??:??:??:07 <= the same each time
X-Sonos-Api-Key: 8??????e-7??7-4??f-b??6-7??????????0 <= the same each time
X-Sonos-Corr-Id: 648ec896-e043-44f8-bfba-cd0a80c9d857 <= unique each time
checking both "Include SMAPI context headers with all requests" and "Include Zone Player IDs in credentials header" capabilities in the customsd page of my Sonos device (I tried this following the answer to this sonos tagged stackoverflow question Now that device ID is deprecated, is there another way to identify the client?)
The docs links I mentioned above that refer the presence of the auth token inside the HTTP Authorization header are the following:
the GET /context CQ API method page says to return 401 Unauthorized when "The access token has expired or is invalid."
the GET /itemWindows CQ API method page says "the player can use this API to obtain a new access token in the response from your cloud queue server" and "The request contains the access token in the authorization header" and "If the access token is set to expire soon, an updated one is included in the X-Updated-Authorization header of the response"
the POST /timePlayed CQ API method page says "The request header contains the access token in the authorization header" and that the method returns ERROR_SONOS_TOKEN_EXPIRED when "SMAPI OAuth token is expired, and user must re-authorize the account"
the GET /version CQ API method page says again that "The request contains the access token in the authorization header" and talks about a now deprecated updateToken parameter and also says that "If the access token is set to expire soon, you should include an updated token in the X-Updated-Authorization header."
But the most clear mention is in the page about HTTP requests, because it's not particular just for the CQ API endpoints but for all HTTP endpoints, even those hosted by the SMAPI server itself. The page reads the following 2 excerpts:
and
To conclude, with so many mentions of it in the official Sonos docs, why isn't this essential header being transmitted in the HTTP Authorization header? And how should a CQ verify the identity of the requester without the presence of this authToken on each API method request?
The auth token is sensitive information and will not be included in the HTTP headers if it's being sent to an endpoint that is insecure.
Try again with your CQ server behind an https:// address.
If I follow you correctly, the token is passed in the header under loginToken, see https://developer.sonos.com/build/content-service-add-features/add-authentication/use-authentication-tokens/
This is not an http header, this is a section of the SOAP envelope. Like this:
I am trying to carry out a test as like it explained here:
JMeter Alter HTTP Headers During Test.
Quote from above :
I'm attempting to test an HTTP service with JMeter. The HTTP service requires authentication through a simple bearer token mechanism. I'm trying to proceed as follows:
POST authentication request Store token as a variable
Set Authorization HTTP header to stored variable
Request protected resource(s)
Evaluate performance
When the POST occurs, I am not able to capture the bearer token. Its a header.
I tried the solution provided by Dmitri on that issue Or as Bennet tried with RegEx Extractor and HTTPs Manager.
I think I am doing something silly not to able to extract the token. Any thoughts how to extract the token?
Most likely your Regular Expression Extractor configuration is not correct, by default it:
uses response body as a source therefore you need to switch it to look into response headers (red rectangle)
looks up in main sample only, if your header is set after redirect it won't be processed (amber rectangle)
Example configuration:
You can double check ${bearer} variable value using Debug Sampler and View Results Tree listener combination.
I have to migrate from Google OAuth 1.0 to OAuth 2.0.
I just have wrote a small request in Chrome Rest Client:
POST: https://accounts.google.com/o/oauth2/token
Headers: Authorization: OAuth realm="", oauth_signature="PU3W5uRL0eAyEi", oauth_nonce="1396865138306881000", oauth_signature_method="HMAC-SHA1", oauth_consumer_key="XXXXX.apps.googleusercontent.com", oauth_token="YYYYY", oauth_timestamp="1396865138", Content-Type: application/x-www-form-urlencoded
Payload: grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1&client_id=ZZZZZ.apps.googleusercontent.com&client_secret=SSSSS
For that I receive an error message:
Status: 400 Bad Request
"{
error: "invalid_request"
error_description: "Invalid authorization header."
}"
The problem could be that I try to migrate from one Project in Google Developers Console to another.
Could that really be a problem?
The reason that I moved to another project is because I cannot create OAuth 2.0 Client ID in the original Project. I receive the following error message:
"You can not create OAuth 2.0 client ID because this project already contains an Oauth 1.0 client ID."
Please suggest.
Thank you,
E
As pointed out in a similar post, when constructing the base string to sign your migration requests, please make sure that the string uses a POST method and that it contains all relevant migration parameters as per the migration documentation.
As per OAuth1 spec, a valid base string for a migration request should look like:
POST&https://accounts.google.com/o/oauth2/token&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1&oauth_consumer_key=YOUR_CONSUMER_KEY&oauth_nonce=NONCE&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1396414006&oauth_token=THE_TOKEN_TO_MIGRATE
Note that, for readability purpose, the above is the decoded version of the base string (check out the OAuth1 spec for more examples).
Hope that helps, Miguel.
When generating the base string you will need to ensure that each individual parameter is URL encoded before constructing the base string.
As per the oAuth documentation to sign OAuth 1.0 requests the base string is made up of 3 components
The HTTP request method
The base URL the request is being sent to
A normalized string of the parameters in the request
When constructing the base string you need to do the following
Ensure HTTP request method is POST
URL encode the base URL
Ensure the three POST body parameters [client_id, client_secret, grant_type] are included in the normalized request parameters
Ensure each parameter is individually URL encoded and then URL encode the complete normalized request parameters string. So in effect, some of the paramters are double URL encoded. This double URL encoding is mentioned in Using OAuth with the Google Data APIs#Signing Requests for the oauth_token
Only after doing all these steps did I get the migration request to work and I received a valid refresh_token
Below is a sample base string
POST&https%3A%2F%2Faccounts.google.com%2Fo%2Foauth2%2Ftoken&client_id%3Dxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com%26client_secret%3Dxxxxxxxxxxxx%26grant_type%3Durn%253Aietf%253Aparams%253Aoauth%253Agrant-type%253Amigration%253Aoauth1%26oauth_consumer_key%3Dxxxxxxxxx%26oauth_nonce%3D4106001%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1400779530%26oauth_token%3D1%252FkklP1YPy_AULt7j_tttttt_tterwerkj_dfj45dflk