The Azure Notification Hubs REST API documentation for "Read All Registrations of a Channel" states to use following request URI (e.g. for Apple Push Notification Service device tokens), which doesn't work: https://{namespace}.servicebus.windows.net/{NotificationHub}/registrations/?$filter=DeviceToken eq ‘{deviceToken}’&api-version=2013-08
I always get the HTTP response code 400 (Bad Request. Notification hubs do not support this query).
Even more confusing, the german version of the documentation uses double quotes, which doesn't work either and gives me the same response code: https://{Namespace}.servicebus.windows.net/{Benachrichtigungshub}/registrations/?$filter=DeviceToken eq "{Gerätetoken}"&api-version=2013-08
What is the correct format for requesting all Azure Notification Hubs registrations of a channel using the REST API?
The request URI must be in this format: https://{namespace}.servicebus.windows.net/{NotificationHub}/registrations/?$filter=DeviceToken+eq+'{deviceToken}'&api-version=2013-08
+ instead of spaces (actually URL encoding the spaces (%20) will also work)
'' (apostrophe / straight single quote - U+0027) instead of ‘’ (single curved quotation marks - U+2018 and U+2019) or "" (straight double quote - U+0022)
Example: https://myServiceBusNamespace.servicebus.windows.net/myHub/registrations/?$filter=DeviceToken+eq+'2ED202AC08EA9033665E853A3DC8BC4C5E78F7A6CF8D55910DF230567037DCC4'&api-version=2013-08
Related
I have this mostly working. All events sent by Github end up on my SQS Queue. The webhook is sending application/json with "Send me everthing" at the org-level. I'm using the following template mapping in my API Gateway:
Action=SendMessage&MessageBody={
"bodyJson":"$util.base64Encode($util.json('$'))",
"requestId":"$context.requestId",
"resourcePath":"$context.resourcePath",
"apiId":"$context.apiId",
"stage":"$context.stage",
"resourceId":"$context.resourceId",
"path":"$context.path",
"protocol":"$context.protocol",
"requestTimeEpoch":"$context.requestTimeEpoch",
"X-GitHub-Event":"$method.request.header.X-GitHub-Event",
"X-GitHub-Delivery":"$method.request.header.X-GitHub-Delivery",
"X-Hub-Signature":"$method.request.header.X-Hub-Signature"
}
(I've also tried '"bodyJson":"$util.base64Encode($util.body)",')
About 5% of event notifications (of various event types, e.g.: status, push) from Github fail to transform properly. When I go to base64 decode messages from the queue, I get part message/part random junk. Have noticed that resending the same event fails on every retry. (The event looks like well-formed json in the Github UI though.) I'm logging to cloudwatch, but the logs are truncated. So I can't tell how much of the original message gets through. I've also tried setting application/json as a binary media type. That just caused all events to fail on transform and return 500 to Github. Anyone know what I'm doing wrong or if this is a bug?
Update
Need to test a bit more, but think I've figured it out. We need to urlEncode the base64Encoded bodyJson because base64 encoding output includes characters (+ and /) that are not application/x-www-form-urlencoded compatible without being url encoded:
Action=SendMessage&MessageBody={
"bodyJson":"$util.urlEncode($util.base64Encode($input.body))",
"requestId":"$context.requestId",
"resourcePath":"$context.resourcePath",
"apiId":"$context.apiId",
"stage":"$context.stage",
"resourceId":"$context.resourceId",
"path":"$context.path",
"protocol":"$context.protocol",
"requestTimeEpoch":"$context.requestTimeEpoch",
"X-GitHub-Event":"$method.request.header.X-GitHub-Event",
"X-GitHub-Delivery":"$method.request.header.X-GitHub-Delivery",
"X-Hub-Signature":"$method.request.header.X-Hub-Signature"
}
Note - I am very much new to all this. Apologies if anything is unclear.
My overriding aim is to pull out MOT history data for a large batch of vehicles from the DVLA API. I understand that this can be done using Postman, which I am using (on a 64-bit Windows laptop if at all relevant).
The DVLA provide the following instructions
====================================================
Getting started
All API interfaces are implemented as restful APIs and accessed over https.
To access API you will need an API key that uniquely identifies the source of the request. DVSA will give you an API key if it approves your application.
You should keep your API key secure, as DVSA manages throttling and quotas at an API key level.
Each request must have the following mandatory fields in the header:
Accept: application/json+v6
x-api-key:
Content-type field confirms that the response type is in JSON format, and the x-api-key field serves your API key to identify the source of the request.
Technical resources
Access the API at https://beta.check-mot.service.gov.uk/
This root URL will change when the service moves from beta to live.
These 4 endpoints equate to the 4 methods of using the API:
/trade/vehicles/mot-tests?registration={registration}
‘Registration’ is the vehicle registration number.
===================================================
In order to test that this is possible, I am entering the following single request into the bar in Postman, selecting "POST" and hitting "SEND"
https://beta.check-mot.service.gov.uk/trade/vehicles/mot-tests?Content-type=application/json&x-api-key=ABCDEFGH®istration=MYREG
n.b. no inverted commas or other punctuation surrounds the actual values for ABCDEFH or MYREG
Expected result: Some sort of JSON with MOT history for this vehicle
Actual result: {"message": "Missing Authentication Token"}{"message": "Missing Authentication Token"}
I am unclear on:
- whether I should be using POST
what the +v6 after the application is necessary (other documentation leaves it out)
Why "Accept" and "Content-type" appear to be used interchangeably in the documentation
Whether the ordering of the parameters matters
Whether this can be equally tested by simply pasting the url into a browser
Thanks for any help
Reading through the Documentation found here:
https://dvsa.github.io/mot-history-api-documentation/
It mentions that those fields should be added as Headers:
Each request must have the following mandatory fields in
the header:
- Accept: application/json+v6
- x-api-key: <your api key>
There are example cURL requests on the site to help you with creating the request.
If you use Postman's Import feature within the app (found in the top right), you can add this cURL request in the Paste Raw Text tab.
curl -H "Accept: application/json+v6" -H "x-api-key: <your_api_key>" https://beta.check-mot.service.gov.uk/trade/vehicles/mot-tests\?registration=ZZ99ABC
This will give you an example request of what it should look like. From here, you will be able to add in your own API Token and send the request.
If you are using Postman, you can use the Authorization tab right under the request to give the required mandatory header fields. Select Header from Add to drop down. You can also add additional headers information using the next tab named Headers. (for example, the accept-headers).
Edit:
Authorization:
Headers Tab
Normally, you should be getting the authorization token when you register to the site in question(x-api-key here).You need to figure out the value of that token from the initial call's response headers. According to the document which Danny shared, you will be getting x-api-key from them once they approve your request.
Edit:
Alternatively, you can use import feature as Danny suggested in his answer. At the end of the day, you need to add the values as headers instead of query parameters.
For anyone using Python with the MOT history api and getting the same error message, try GET:
import requests
url = f'https://beta.check-mot.service.gov.uk/trade/vehicles/mot-tests?registration={plate_number}'
payload = {}
headers = {
'Accept': 'application/json+v6',
'x-api-key': 'your-api-key'}
response = requests.get(url, headers=headers, data=payload)
data = response.json()
model = data[0]['model'] # get the vehicle model for example
print(model)
I'm using the Actions on Google OAUTH authorization flow. In the authorization URL, Google passes along a very long "state" parameter (500+ char) in the URL, yielding an error on the OAauth client/server (Bunq to be precise).
I've seen more cases where this is an issue, also including Amazon Skills.
If I manually shorten the length of the 'state' parameter, the error disappears. But since Google is using the 'state' parameter as a "bookmarking value", they do not allow for any alterations. There seems to be no way to resolve this issue on my side.
Here is an example of the Authorization URL that is generated by Actions on Google:
https://oauth.bunq.com/auth?redirect_uri=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2F[MY PROJECT NUMBER]&client_id=[CLIENT ID]&response_type=code&state=[567 CHARACTERS]
Is there a way to shorten the state parameter, or to resolve this issue otherwise?
While there is no specified limit on the characters forming a URL specified by the Network Working Group in RFC 2616, the defacto convention used by many internet systems and browsers is up to 2k characters. You should check with the internal codebase as well if there is any limit on the number of characters that can be included in a query string.
I am using aws api gateway to send a http proxy to my server - if the user is authenticated, and need to send the user's username to my server for identification purpose.
if I use the $context variable in body mapping ($context.authorizer.claims['cognito:username']) then I get the value as required but if i try to use the same in header section then I dont get it. I even try a static header key/value and it works
Here's a snapshot to explain.
Please let me know - how do i get the required data in the header section
Note: TO TEST THE FUNCTIONALITY - I HAVE CREATED A NEW ENDPOINT AND SENDING ALL THE REQUEST TO A LAMBDA and NOT TO MY SERVER FOR NOW. I tried sending it to my server as well - but both endpoint fails to get the username in header section
At last - Got it solved
In the header section - there seems to be some issue with ['cognito:username'] - array syntax - that's why it didn't used to work
It worked with context.authorizer.claims.cognito:username (no single quotes)
and in Body mapping - you still need to use $context.authorizer.claims['cognito:username']
the above header section syntax doesnt work on Body mapping
In Header we need to
context.authorizer.claims.cognito:username
In Body MApping we need
$context.authorizer.claims['cognito:username']
The Watson Speech-to-Text asynchronous HTTP interface allows one to register a callback url through a call to register_callback. This call is clearly not working; for illustration, please see these six lines of code.
# Illustration of how I can't get the Watson Speech-to-Text
# register_callback call to work.
r = requests.post(
"https://stream.watsonplatform.net/speech-to-text/api/v1/register_callback?{0}".format(
urllib.urlencode({ "callback_url": callback_url })),
auth=(watson_username, watson_password),
data="{}")
print(r.status_code)
print(pprint.pformat(r.json()))
# This outputs:
# 400
# {u'code': 400,
# u'code_description': u'Bad Request',
# u'error': u"unable to verify callback url 'https://xuyv2beqpj.execute-api.us-east-1.amazonaws.com/prod/SpeechToTextCallback' , server responded with status code: 400"}
# and no http call is logged on the server.
r = requests.get(
callback_url, params=dict(challenge_string="what does redacted mean?"))
print(r.status_code)
print(r.text)
# This outputs:
# 200
# what does redacted mean?
# and an HTTP GET is logged on the server.
I first call register_callback with a perfectly valid callback_url parameter, in exactly the way the documentation describes. This call returns with a 400 and, according to my callback URL server logs, the callback URL never receives an HTTP request. Then I GET the callback URL myself with a challenge_string. Not only is the callback URL responding with the right output, but a log appears on my server indicating the URL received an HTTP request. I conclude that register_call is not working.
Answer:
We identified the issue on our end: the server that makes the outbound calls to your URL did not support the SSL encryption method that your callback server uses. We have fixed that and we are in the process of pushing to the production environment very soon.
Also FYI:
The error message with 400 indicates the callback URL does not meet
request or does not exist. Please refer to the detail in
Speech-To-Text service API document,
http://www.ibm.com/watson/developercloud/speech-to-text/api/v1/?curl#register_callback
If the service does not receive a response with a response code of 200
and a body that echoes a random alphanumeric challenge string from the
callback URL within 5 seconds, it does not whitelist the URL; it
sends response code 400 in response to the registration request.
we just fixed the issue you reported. The problem was on our end, the servers responsible for making the callback to the server you set up did not support the cipher suites needed for establishing the SSL connection. We just updated the servers and we are happy to learn that it is now working for you: )
Dani