I experienced issue in Uber rides API. Basically what happened was that the ride cancel endpoint returned 204 success response, but ride wasn't canceled.
This was first request:
curl -XDELETE -H 'Authorization: Bearer xxx' \
-H 'Accept-Language: en_US' \
-H 'Content-Type: application/json' \
'https://sandbox-api.uber.com/v1.2/requests/45546b81-cea5-4406-bde6-b574796606b8'
After that I received webhooks with ride canceled status and receipt ready:
{"event_id": "fbba171c-11b9-4081-b473-51ca19c35ceb", "resource_href": "https://sandbox-api.uber.com/v1/requests/45546b81-cea5-4406-bde6-b574796606b8/receipt", "meta": {"status": "ready", "rider_id": "xxx", "user_id": "xxx", "resource_id": "45546b81-cea5-4406-bde6-b574796606b8"}, "event_type": "requests.receipt_ready", "event_time": 1512401098}
{"event_id": "30d9efaa-f8eb-40f8-a0bd-7bf91ea4f7e3", "resource_href": "https://sandbox-api.uber.com/v1/requests/45546b81-cea5-4406-bde6-b574796606b8", "meta": {"status": "rider_canceled", "rider_id": "xxx", "user_id": "xxx", "resource_id": "45546b81-cea5-4406-bde6-b574796606b8"}, "event_type": "requests.status_changed", "event_time": 1512401098}
But when I asked about status later, returned response said that the status of ride is accepted:
curl -H 'Authorization: Bearer xxx' \
-H 'Accept-Language: en_US' \
-H 'Content-Type: application/json' \
'https://sandbox-api.uber.com/v1.2/requests/45546b81-cea5-4406-bde6-b574796606b8'
{"status":"accepted","product_id":"b8e5c464-5de2-4539-a35a-986d6e58f186","destination":{"latitude":40.783062,"eta":4,"longitude":-73.97125},"driver":{"phone_number":"(555)555-5555","rating":4.9,"picture_url":"https:\/\/d1a3f4spazzrp4.cloudfront.net\/uberex-sandbox\/images\/driver.jpg","name":"John","sms_number":null},"pickup":{"latitude":40.759068,"eta":1,"longitude":-73.98496},"request_id":"45546b81-cea5-4406-bde6-b574796606b8","location":{"latitude":40.75898,"bearing":null,"longitude":-73.98478},"vehicle":{"make":"Toyota","picture_url":"https:\/\/d1a3f4spazzrp4.cloudfront.net\/uberex-sandbox\/images\/prius.jpg","model":"Prius","license_plate":"UBER-PLATE"},"shared":false}
When I send cancel request again, it worked. What happened here?
Related
I have a Keycloak deployed locally with the following Docker command:
docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e
KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:20.0.1
start-dev
I get a token from Keycloak. Example:
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJMZjRfWHJjWkpTaVJYWlFLS254VS1NdU9FTHA4d3NaaHlLMDQ0UjRIRjdnIn0.eyJleHAiOjE2NzAwODc1MDgsImlhdCI6MTY3MDA4NzIwOCwiYXV0aF90aW1lIjoxNjcwMDg2NDcwLCJqdGkiOiIyYWQxODQ5ZC0xMjI0LTQ4YjYtYWZjYy01ZmFjMWZjODY3ZjQiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvcmVhbG1zL2RpYWxvZy1mZWF0IiwiYXVkIjoiYWNjb3VudCIsInN1YiI6IjRkYjdiNjg1LTRkYTAtNGZjMy1iNjI1LTgyZmM1MTdjNjA3NiIsInR5cCI6IkJlYXJlciIsImF6cCI6InNvbWV4NSIsIm5vbmNlIjoiR0tNb1JWRTVDajZSVjJMcFQ1Mjg5eVQ3RUdWeFMzZk4iLCJzZXNzaW9uX3N0YXRlIjoiMTY4Y2JmZGQtMmFmYS00Mjk5LWI4YmUtMmExM2FjMjI2NzJiIiwiYWNyIjoiMCIsInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIiwiZGVmYXVsdC1yb2xlcy1kaWFsb2ctZmVhdCJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoib3BlbmlkIHByb2ZpbGUgZW1haWwiLCJzaWQiOiIxNjhjYmZkZC0yYWZhLTQyOTktYjhiZS0yYTEzYWMyMjY3MmIiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwibmFtZSI6IkpvaG4gU25vdyIsInByZWZlcnJlZF91c2VybmFtZSI6ImpvaG4uc25vdyIsImdpdmVuX25hbWUiOiJKb2huIiwiZmFtaWx5X25hbWUiOiJTbm93IiwiZW1haWwiOiJqb2huLnNub3dAeDUucnUifQ.j_rFqVxICtj7NR-myEsWhSkwBeCABplFrmlBuRMAhF4N8HzdOOtExdmw_mXdx60snKTaE5GJHPofjllpM353lY8H9NGxaczUgL20GjVmMhwtihGGBLpiw7TXyGQGkfdBXdweCuS0W1avegXrhRYvCYlFGJMoxsdmskYkDt4DjuESlTkMEOndVjv5LBp3rLB6lRopq0Qg3Abp_rv57KvlVeeul24OKoisFohnZ4VfsiDPAuVW1u1xaYmjCRDlBwIcGosdwasL_WNAgvJkaKdVtvu7NU-ghPa1vQkWJkMZrVIZDsCc5LKZqwspw3U2iOcUc5EDC6FumBWdfvWCx8cszw
Its payload:
{
"exp": 1670087508,
"iat": 1670087208,
"auth_time": 1670086470,
"jti": "2ad1849d-1224-48b6-afcc-5fac1fc867f4",
"iss": "http://localhost:8080/realms/dialog-feat",
"aud": "account",
"sub": "4db7b685-4da0-4fc3-b625-82fc517c6076",
"typ": "Bearer",
"azp": "somex5",
"nonce": "GKMoRVE5Cj6RV2LpT5289yT7EGVxS3fN",
"session_state": "168cbfdd-2afa-4299-b8be-2a13ac22672b",
"acr": "0",
"realm_access": {
"roles": [
"offline_access",
"uma_authorization",
"default-roles-dialog-feat"
]
},
"resource_access": {
"account": {
"roles": [
"manage-account",
"manage-account-links",
"view-profile"
]
}
},
"scope": "openid profile email",
"sid": "168cbfdd-2afa-4299-b8be-2a13ac22672b",
"email_verified": true,
"name": "John Snow",
"preferred_username": "john.snow",
"given_name": "John",
"family_name": "Snow",
"email": "john.snow#x5.ru"
}
It seems valid. Then I'm making a request to http://127.0.0.1:8080/realms/dialog-feat/protocol/openid-connect/userinfo with the token:
curl --location --request GET
'http://127.0.0.1:8080/realms/dialog-feat/protocol/openid-connect/userinfo'
--header 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJMZjRfWHJjWkpTaVJYWlFLS254VS1NdU9FTHA4d3NaaHlLMDQ0UjRIRjdnIn0.eyJleHAiOjE2NzAwODc1MDgsImlhdCI6MTY3MDA4NzIwOCwiYXV0aF90aW1lIjoxNjcwMDg2NDcwLCJqdGkiOiIyYWQxODQ5ZC0xMjI0LTQ4YjYtYWZjYy01ZmFjMWZjODY3ZjQiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvcmVhbG1zL2RpYWxvZy1mZWF0IiwiYXVkIjoiYWNjb3VudCIsInN1YiI6IjRkYjdiNjg1LTRkYTAtNGZjMy1iNjI1LTgyZmM1MTdjNjA3NiIsInR5cCI6IkJlYXJlciIsImF6cCI6InNvbWV4NSIsIm5vbmNlIjoiR0tNb1JWRTVDajZSVjJMcFQ1Mjg5eVQ3RUdWeFMzZk4iLCJzZXNzaW9uX3N0YXRlIjoiMTY4Y2JmZGQtMmFmYS00Mjk5LWI4YmUtMmExM2FjMjI2NzJiIiwiYWNyIjoiMCIsInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIiwiZGVmYXVsdC1yb2xlcy1kaWFsb2ctZmVhdCJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoib3BlbmlkIHByb2ZpbGUgZW1haWwiLCJzaWQiOiIxNjhjYmZkZC0yYWZhLTQyOTktYjhiZS0yYTEzYWMyMjY3MmIiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwibmFtZSI6IkpvaG4gU25vdyIsInByZWZlcnJlZF91c2VybmFtZSI6ImpvaG4uc25vdyIsImdpdmVuX25hbWUiOiJKb2huIiwiZmFtaWx5X25hbWUiOiJTbm93IiwiZW1haWwiOiJqb2huLnNub3dAeDUucnUifQ.j_rFqVxICtj7NR-myEsWhSkwBeCABplFrmlBuRMAhF4N8HzdOOtExdmw_mXdx60snKTaE5GJHPofjllpM353lY8H9NGxaczUgL20GjVmMhwtihGGBLpiw7TXyGQGkfdBXdweCuS0W1avegXrhRYvCYlFGJMoxsdmskYkDt4DjuESlTkMEOndVjv5LBp3rLB6lRopq0Qg3Abp_rv57KvlVeeul24OKoisFohnZ4VfsiDPAuVW1u1xaYmjCRDlBwIcGosdwasL_WNAgvJkaKdVtvu7NU-ghPa1vQkWJkMZrVIZDsCc5LKZqwspw3U2iOcUc5EDC6FumBWdfvWCx8cszw'
But I get a 401 status code returned. For example:
type=USER_INFO_REQUEST_ERROR, realmId=(...), clientId=null, userId=null, ipAddress=(...), error=access_denied, auth_method=validate_access_token
How to fix this?
My Keycloak settings:
The problem seems to be a mismatch between the issuer of the access token sent to the userinfo endpoint (i.e., "iss": "http://localhost:8080/realms/dialog-feat") and the issuer that the access token validator triggered by the userinfo endpoint is expecting.
Instead of:
Then I'm making a request to
http://127.0.0.1:8080/realms/dialog-feat/protocol/openid-connect/userinfo
with the token (...):
Use the same hostname in the userinfo endpoint has the one that you have used to acquire the access token, for instance:
curl http://localhost:8080/realms/dialog-feat/protocol/openid-connect/userinfo -H "Authorization: Bearer (..<your access token..)"
If the problem still persistes then you also facing the issues related with the Keycloak endpoint implementation described in UserInfo endpoint not fully standards compliant.
In short in your request for a the access token explicitly add the parameter scope=openid. An example:
curl --request POST \
--url "http://localhost:8080/realms/dialog-feat/protocol/openid-connect/token" \
--data client_id=somex5 \
--data username=john.snow \
--data password=...<the password..> \
--data grant_type=password \
--data scope=openid
I am trying the following API request for IBM Cloud Secrets Manager, but it fails:
curl -X POST "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v1/secrets/arbitrary" -H "Authorization: Bearer $IAM_TOKEN" -H "Accept: application/json" -H "Content-Type: application/json" -d '{
"metadata": {
"collection_type": "application/vnd.ibm.secrets-manager.secret+json",
"collection_total": 1
},
"resources": [
{
"name": "example-arbitrary-secret",
"description": "Extended description for my secret.",
"secret_group_id": "432b91f1-ff6d-4b47-9f06-82debc236d90",
"payload: "secret-data",
"expiration_date": "2030-12-31T00:00:00Z",
"labels": [
"dev",
"us-south"
]
}
]
}'
There was a missing double-quote after payload...
curl -X POST "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v1/secrets/arbitrary" -H "Authorization: Bearer $IAM_TOKEN" -H "Accept: application/json" -H "Content-Type: application/json" -d '{
"metadata": {
"collection_type": "application/vnd.ibm.secrets-manager.secret+json",
"collection_total": 1
},
"resources": [
{
"name": "example-arbitrary-secret",
"description": "Extended description for my secret.",
"secret_group_id": "432b91f1-ff6d-4b47-9f06-82debc236d90",
"payload": "secret-data",
"expiration_date": "2030-12-31T00:00:00Z",
"labels": [
"dev",
"us-south"
]
}
]
}'
I am trying to test rest api as mentioned here from Postman. I followed this thread here and tried importing the curl request in Postman but it's failing with the following error:
Here is the complete curl command:
curl \
--header "X-OpenIDM-Username: openidm-admin" \
--header "X-OpenIDM-Password: openidm-admin" \
--header "Content-Type: application/json" \
--request PATCH \
--data '[
{
"operation": "add",
"field": "/members/-",
"value": {"_ref" : "managed/user/scarter"}
}
]' \
"http://localhost:8080/openidm/managed/role/cedadaed-5774-4d65-b4a2-41d455ed524a"
{
"_id": "cedadaed-5774-4d65-b4a2-41d455ed524a",
"_rev": "2",
"name": "employee",
"description": "Role granted to workers on the company payroll"
}
Trying to create a sandbox as described here:
https://developer.yahoo.com/gemini/guide/navigate-the-api/testing/
After trying all sorts of different things, I've ended up with the exact request from the docs:
curl -X POST \
http://sandbox-api.gemini.yahoo.com/v2/rest/advertisersignup \
-H 'Authorization: Bearer nZ8hzgmc5...' \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-H 'Postman-Token: 03e2855d-3f5f-4780-a8f5-014f16bf1fac' \
-d '{
"advertiserName": "sandbox test"
}'
But I keep getting an "invalid email" error.
{
"errors": [
{
"errIndex": -1,
"code": "E40000_INVALID_INPUT",
"message": "[INVALID_EMAIL_ADDRESS]",
"description": ""
}
],
"response": {
"advertiserName": "sandbox test"
},
"timestamp": "2018-07-30 22:08:07"
}
Am I missing something?
we are testing the subscription functionality using the APIv2. We are following the guidelines described in http://telefonicaid.github.io/fiware-orion/api/v2/ . We are able to create a correct subscription but the format of the notification messages that we received is not what we expected. The format of these messages is like the APIv1 version. Is this the expected behavior?
We are using the Docker image from https://hub.docker.com/r/fiware/orion/.
Version information about the build:
{
"orion" : {
"version" : "1.0.0-next",
"uptime" : "0 d, 1 h, 28 m, 47 s",
"git_hash" : "a729812c45d2749fffbc19add17631b2fffc8797",
"compile_time" : "Fri Apr 8 10:05:55 UTC 2016",
"compiled_by" : "root",
"compiled_in" : "838a42ae8431"
}
}
Steps to reproduce:
Create an entity:
(curl -X POST http://<cb_url>:<cb_port>/v2/entities?options=keyValues -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"type":"Room",
"id": "test",
"humidity":40
}
EOF
Create a subscription:
(curl -X POST http://<cb_url>:<cb_port>/v2/subscriptions -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"description": "One subscription to rule them all",
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "Room"
}
],
"condition": {
"attributes": [
"humidity"
],
"expression": {
"q": "humidity>40"
}
}
},
"notification": {
"callback": "http://192.168.99.1:5000",
"attributes": [
"humidity"
],
"throttling": 5
},
"expires": "2016-05-05T14:00:00.00Z"
}
EOF
Update attribute.:
(curl -X PUT <cb_url>:<cb_port>/v2/entities/test/attrs/humidity/value -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"value": 50
}
EOF
We get the notification with the following format:
{u'contextResponses': [
{u'contextElement': {
u'attributes': [{
u'name': u'humidity',
u'type': u'none',
u'value': {u'value': 50}
}],
u'id': u'test',
u'isPattern': u'false',
u'type': u'Room'
},
u'statusCode': {
u'code': u'200',
u'reasonPhrase': u'OK'
}}],
u'originator': u'localhost',
u'subscriptionId': u'5707b72882fc213130f4e5b9'}
NGSIv2 notification formats have not been yet implemented (at Orion 1.0.0). Note that NGSIv2 is yet in beta status and sometimes the specification (where the new notification format has been defined) is a step forward the implementation.
There is a github issue about this, to which you can subscribe in order to know when this feature gets implemented.
EDIT: NGSIv2 notification formats have been implemented in Orion 1.1.0.