How to format responses of ec2 endpoint to json - rest

I am trying to perform a GET-Request to the ec2-Endpoint https://ec2.eu-central-1.amazonaws.com/?Action=DescribeInstances&Version=2016-11-15 in order to get a list of all ec2 instances within my aws account (in eu-central-1 region). Unfortunately the response's content is formatted in xml. Is there a chance to change the format of the response to json?
I've already set the GET-Request's Accept-Header to "application/json" but without success.
If I query the iam-endpoint https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08 with the same Accept-Header the response's content is being delivered properly in json string format.
These are the headers for the ec2-query (not working):
GET /?Action=DescribeInstances&Version=2016-11-15 HTTP/1.1
Host: ec2.eu-central-1.amazonaws.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
X-Amz-Date: 20180706T091958Z
Authorization: <valid AWS4 authorization header>
Cache-Control: no-cache
Postman-Token: 69c8f349-95b5-4e9d-991c-5ce2a55b0cbe
And the headers of my iam-query (working):
GET /?Action=ListUsers&Version=2010-05-08 HTTP/1.1
Host: iam.amazonaws.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
X-Amz-Date: 20180706T092222Z
Authorization: <valid AWS4 authorization header>
Cache-Control: no-cache
Postman-Token: ad86f2ae-870c-4289-a9d3-1f2ad9082c8f
Executing aws cli tools command aws ec2 describe-instances lists all instances in json format, so I think there should be a way to achieve this with a GET-request.
Thank you very much for your help.

Probably too late, but might help others.
I also tried to get json output from DescribeInstances without luck.
It seems to be impossible at the moment, since even aws cli receives it in xml and then converts it to json. You can see it using --debug flag:
aws ec2 describe-instances --debug

Related

Unable to call TFS 2017 REST APIs

When I connect to my on prem TFS server version 15.117.27414.0 using the url
GET http://{instance}/{collection}/{project}, I get a 200 OK using Basic Authentication with Base64 of PAT.
However, when I make an API call on this url say GET http://{instance}/{collection}/{project}/_apis/serviceendpoint/endpoints?api-version=3.2, I get a 404 error.
Request Header-
Content-type: application/json
Accept: application/json
Authorization: Basic ###########################
What am I doing wrong here?
That's not the correct URI.
https://learn.microsoft.com/en-us/azure/devops/integrate/previous-apis/endpoints/endpoints?view=tfs-2017
The URI would be:
_apis/distributedtask/serviceendpoints

sapui5 OData.V4.oDataModel with Teiid 11.2 / Wildfly

I am trying to use SAPUI5 in a SPA to display data from a TEIID/Wildfly ODataV4 service. When SAPUI5 ODATA V4 data model is bound to the service, I run into several errors. I thereby connect via proxy (grunt-connect-proxy2) to the odata service. Basic Auth works. The metadata file above the marked service folder in the attached image (screenshot1) is the actual metadata file of the service which, as you can see, is loaded correctly. So no CORS issue or authorization issue.
Screenshot1
The issue seems to be related to an CSRF Token request as far as I understand. Seems that Teiid/Wildfly is not answering the CSRF Token fetch request. Is there a way to configure Wildfly to answer the request or alternatively a way to disable CSRF requests for the odata V4 model? I have seen such an option in the constructor of the odata V2 model. How could a working configuration look like?
The following is a screenshot from the browser log:
I observed a further issue, from which I do not know if it is related to the previous one (there is also a X-CSRF-Token: Fetch involved), or if a have something more missing somewhere. The second issue happens when I use an aggregation binding to bind a odata collection to a sapui5 list. The response looks like
Request URL: http://localhost:9001/odata4/svc/my_nutri_diary/$batch
Request Method: POST Status Code: 406 Not Acceptable Remote Address:
[::1]:9001 Referrer Policy: no-referrer-when-downgrade Response
Headersview source access-control-allow-credentials: true
access-control-allow-origin: http://localhost:9001 cache-control:
no-cache, no-store, must-revalidate connection: close
content-encoding: gzip content-length: 125 content-type:
application/json;odata.metadata=minimal date: Mon, 12 Nov 2018
20:04:30 GMT expires: 0 odata-version: 4.0 pragma: no-cache server:
WildFly/11 x-powered-by: Undertow/1 Request Headersview source Accept:
multipart/mixed Accept-Encoding: gzip, deflate, br Accept-Language: de
Authorization: Basic SU1TVXNlcjpJTVM0Zm9ydW0l Connection: keep-alive
Content-Length: 329 Content-Type: multipart/mixed;
boundary=batch_id-1542053070786-11 Cookie: sidebar_collapsed=false;
cycle_analytics_help_dismissed=1;
__utmz=111872281.1539128843.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=111872281.767670437.1539128843.1541866362.1541870562.42 DNT: 1 Host: localhost:9001 MIME-Version: 1.0 OData-MaxVersion: 4.0
OData-Version: 4.0 Origin: http://localhost:9001 Referer:
http://localhost:9001/ User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS
11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko)
Version/11.0 Mobile/15A372 Safari/604.1 X-CSRF-Token: Fetch
X-Requested-With: XMLHttpRequest Request Payload
--batch_id-1542053070786-11 Content-Type:application/http Content-Transfer-Encoding:binary GET Profile?$skip=0&$top=100 HTTP/1.1
Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
Accept-Language:de
Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
--batch_id-1542053070786-11--
Thanks for your advice!
Best regards,
Christoph
Further note regarding search for a workaround: As I am currently searching for a workaround to be able to use the odata.v4 model, I found the following blog post:
https://blogs.sap.com/2015/08/05/disable-csrf-token-for-odata-calls-using-sap-netweaver-gateway/
However, the approach does not seem to work for the odata.v4 model as it has a different interface. There is no setHeaders() function to set custom headers on the datamodel. I therefore tried to set the header up via
$.ajaxSetup({headers: {'X-Requested-With': 'X'}});
Unfortunately, this also does not work. If someone has the odata.v4 Model running with TEIID or Olingo v4 it would be great if he could give me a feedback on how he had worked around this issue.

Amazon AWS Machine Learning HTTP request

I have created AWS Machine Learning model with working real-time endpoint. I want to consume created service via HTTP request. For testing purpose I'm using Postman, I've created request according to Amazon's API documentation but every time I get the same exception: UnknownOperationException. While I'm using Python SDK the service is working fine. Below example that gets model info.
That's my request (fake credentials):
POST HTTP/1.1
Host: realtime.machinelearning.us-east-1.amazonaws.com
Content-Type: application/json
X-Amz-Target: AmazonML_20141212.GetMLModel
X-Amz-Date: 20170714T124250Z
Authorization: AWS4-HMAC-SHA256 Credential=JNALSFNLANFAFS/20170714/us-east-1/AmazonML/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-date;x-amz-target, Signature=fiudsf9sdfh9sdhfsd9hfsdkfdsiufhdsfoidshfodsh
Cache-Control: no-cache
Postman-Token: hd9sfh9s-idsfuuf-a32c-31ca-dsufhdso
{
"MLModelId": "ml-Hfdlfjdof0807",
"Verbose": true
}
Exception I get:
{
"Output": {
"__type": "com.amazon.coral.service#UnknownOperationException",
"message": null
},
"Version": "1.0"
}
After doing research on AWS forum I've found some similar HTTP requests. Turns out I had 3 incorrect parameters.
Host address should be:
Host: machinelearning.us-east-1.amazonaws.com
Content type:
Content-Type: application/x-amz-json-1.1
In credentials parameters target service has to be specified as machinelearning
Short instruction how to setup Postman's request:
In Authorization tab choose AWS Signature and fill in AccessKey and SecrectKey. In Service Name field write machinelearning. Click Update Request, this will update your header.
In Headers tab add two headers:
Key: X-Amz-Target, Value: AmazonML_20141212.GetMLModel
Key: Content-Type, Value: application/x-amz-json-1.1
Add body:
{ "MLModelId": "YOUR_ML_MODEL_ID", "Verbose": true }
Correct HTTP request below:
POST HTTP/1.1
Host: machinelearning.us-east-1.amazonaws.com
X-Amz-Target: AmazonML_20141212.GetMLModel
Content-Type: application/x-amz-json-1.1
X-Amz-Date: 20170727T113217Z
Authorization: AWS4-HMAC-SHA256 Credential=JNALNFAFS/20170727/us-east-1/machinelearning/aws4_request,
SignedHeaders=content-length;content-type;host;x-amz-date;x-amz-target,
Signature=fiudsf9sdfh9sdhfsd9hfsdkfdsiufhdsfoidshfodsh
Cache-Control: no-cache
Postman-Token: hd9sfh9s-idsfuuf-a32c-31ca-dsufhdso
{
"MLModelId": "ml-Hfdlfjdof0807",
"Verbose": true
}
Please check following link and validate your sigv4
http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html

URLSession on Linux giving different result than on iOS

I've got a simple class making a HTTP POST request (to a Neo4j server, but that shouldn't matter) using URLSession, and an integration test that tests that it succeeds.
Through Xcode, via the iOS simulator, I can run this test a million times - it succeeds every time.
However, when I run swift test on Ubuntu Linux (I use the docker image provided by IBM) then I very often will get a test failure saying I got a 401 response.
Replicating that via cURL in the container does not fail at all, so I do not believe this to be a problem with my container.
I have added a packet dump (that I inspect via Charles Proxy) where our of 15 test runs, 7 test runs (and thus 7 requests) fail. All of the failed requests complain that no authentication header was supplied. And from the dump, that is correct, the dump does not contain the authentication header for those requests that fail. But why not? In fact, all of the header flags are different: a successful run has these headers:
POST /db/data/cypher HTTP/1.1
Host: 192.168.0.18:7474
Accept-Encoding: deflate, gzip
Authorization: Basic bmVvNGo6c3RhY2swdmVyRmxvdw==
Content-Type: application/json; charset=utf-8
Accept: application/json; charset=utf-8
Connection: keep-alive
User-Agent: urlsessionTestPackageTests.xctest (unknown version) curl/7.35.0
Content-Length: 135
while an unsuccessful one has these:
POST /db/data/cypher HTTP/1.1
Host: 192.168.0.18:7474
Accept: */*
Accept-Encoding: deflate, gzip
Connection: keep-alive
User-Agent: urlsessionTestPackageTests.xctest (unknown version) curl/7.35.0
Content-Length: 135
All the 200 results have the same headers, and all the 401 results have the same headers. Can you see anything in my code that should warrant such a random request?

Azure Media Services AssetDeliveryPolicies in REST Api - do they gone?

I'm writing application in which i upload video, encode it, and then i need to expose a link to encoded video. One of the steps is to create AssetDeliveryPolicies and link it to Asset, i tried to do that, but to my surprise i don't see such entity as AssetDeliveryPolicies on that endpoint:
https://wamsamsclus001rest-hs.cloudapp.net/api/AssetDeliveryPolicies
Do anybody have tried to do something like that? I'm not sure whether i'm doing something wrong or it is already deprecated and handled in some other way.
Create an AccessDeliveryPolicy
POST https://media.windows.net/api/AssetDeliveryPolicies HTTP/1.1
Content-Type: application/json
DataServiceVersion: 1.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
Accept: application/json
Accept-Charset: UTF-8
Authorization: Bearer [token here]
x-ms-version: 2.11
x-ms-client-request-id: [guid here]
Host: media.windows.net
{"Name":"Clear Policy",
"AssetDeliveryProtocol":7,
"AssetDeliveryPolicyType":2,
"AssetDeliveryConfiguration":null}
Link an AssetDeliveryPolicy to an Asset.
POST https://media.windows.net/api/Assets('nb%3Acid%3AUUID%3A86933344-9539-4d0c-be7d-f842458693e0')/$links/DeliveryPolicies HTTP/1.1
DataServiceVersion: 1.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
Accept: application/json
Accept-Charset: UTF-8
Content-Type: application/json
Authorization: Bearer [token here]
x-ms-version: 2.11
x-ms-client-request-id: [new guid here]
Host: media.windows.net
{"uri":"https://media.windows.net/api/AssetDeliveryPolicies('nb%3Aadpid%3AUUID%3A92b0f6ba-3c9f-49b6-a5fa-2a8703b04ecd')"}
Where nb%3Acid%3AUUID%3A86933344-9539-4d0c-be7d-f842458693e0 is the URL Encoded value of AssetId and nb%3Aadpid%3AUUID%3A92b0f6ba-3c9f-49b6-a5fa-2a8703b04ecd is the URL Encoded value of the AccessDeliveryPolicy Id.
Source