I am new with Postman, so bare over with me if the answer is obvious. I am trying to simulate a facebook request. So I go to crome and find the request in the developer tool and click copy curl:
curl 'https://www.facebook.com/api/graphql/' -H 'origin: https://www.facebook.com' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9,da-DK;q=0.8,da;q=0.7,und;q=0.6' -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36' -H 'content-type: application/x-www-form-urlencoded' -H 'accept: */*' -H 'referer: https://www.facebook.com/pg/KotaSchuetz/photos/?ref=page_internal' -H 'authority: www.facebook.com' -H 'cookie: dpr=2; datr=YeRHXauuPweQJ5Y9_hZALUiq; sb=ZeRHXepAsanc2lyq01n6t23u; _fbp=fb.1.1564993022377.743027707; locale=da_DK; wd=1050x922; fr=1lIqKU0zJAQIo53kV.AWVl5Lq64t5KT28UV1IDdZPTDcI.BdR-Rj.aX.F1H.0.0.BdR-jk.AWVxxFkJ' --data 'av=0&__user=0&__a=1&__dyn=7xeUmFoHw_Jxl0BCwDKEyGgS8USQjFCwloS2Sq5-axubwTwywTxqbyQdxK5WAxacyUuKcUfFU9EgzoS2Sih6UXwCg898Gicx21LxiUd8hwj8lwCAx2i10GfzEWq686yl0Dwxzo8ofHG3q5U4aE4a3mbzUeU-1dx3ximfVEW8wRK4ovyp8rAUG2GXxK8wDxC5oOEiKm2e14zU4G8xGErxCcyE9XAy8aElxWWzU4K8DwGy85i5o9kbxSu68vwlo9oow8m2WE9EjwaO&__req=n&__be=1&__pc=PHASED%3ADEFAULT&dpr=2&__rev=1001018175&__s=%3Aa1kp7i%3A4ymz6z&__hsi=6721596602655958753-0&lsd=AVr5P4v6&jazoest=2622&__spin_r=1001018175&__spin_b=trunk&__spin_t=1564993663&fb_api_caller_class=RelayModern&fb_api_req_friendly_name=PagePhotosTabAllPhotosGridPaginationQuery&variables=%7B%22count%22%3A28%2C%22cursor%22%3A%22AQHRY8pI2Gl64JePNDFCnYYzMZ-_vkWFc4R3L5fSQ5N0u62K0R68giUtxgLUZ7hZVGIOJ3B79Tu-3WHFO8N6jJSARw%22%2C%22pageID%22%3A%22200168320060101%22%7D&doc_id=1887586514672506' --compressed
Then I import it into Postman. It seems like headers etc are copied as expected to postman. However I get following response? Any pointers, is it some https certificate thing i need to configure?
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 2 months ago.
Improve this question
I know if Access-Control-Allow-Origin is a wildcard *, script X cannot be accessed from an origin Y when the request's credentials mode is 'include'. Fair enough!
Normally, when we have Nginx, we solve this by something like:
add_header 'Access-Control-Allow-Origin' $http_origin;
From what I understood, seems like there is no $http_origin equivalent in Google Cloud storage (or is there?).
So, if the resource is in Google Cloud storage, I don't know how can I adjust the CORS setting to do the same.
I currently do the following:
$ printf '[{"origin": ["*"],"responseHeader": ["*"],"method":
["GET","POST","HEAD"],"maxAgeSeconds": 900}]' > cors.json
$ gsutil cors set cors.json gs://mybucket
$ gsutil -m rsync -a public-read ./myfolder/ gs://mybucket/myfolder/
The error I received, as I said, is this:
Access to script at 'https://storage.googleapis.com/mybucket/myfolder/myfile.js' from origin 'https://www.whatever.com' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
My question is specifically about Google Cloud storage settings: how can I fix this issue for static files I'm uploading to Google Cloud storage?
Update 1:
This resource is a public url and can be called from any HTTPS website, even the ones that we don't explicitly know about.
Here is the screenshot of the error:
Update 2:
Here is the request cURL I copy pasted from network tab in Chrome:
curl 'https://storage.googleapis.com/whatever/whatever/file.js' \
-H 'authority: storage.googleapis.com' \
-H 'accept: */*' \
-H 'accept-language: en-US,en;q=0.9' \
-H 'cache-control: no-cache' \
-H 'origin: https://www.example.com' \
-H 'pragma: no-cache' \
-H 'referer: https://www.example.com/' \
-H 'sec-ch-ua: "Google Chrome";v="107", "Chromium";v="107", "Not=A?Brand";v="24"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'sec-ch-ua-platform: "macOS"' \
-H 'sec-fetch-dest: script' \
-H 'sec-fetch-mode: cors' \
-H 'sec-fetch-site: cross-site' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36' \
--compressed
The problem was the crossorigin settings of the generated tag. The problem was resolved after setting it to anynomous.
We have transferred our website to a new AWS account. Which meant moving all the images into a new bucket and setting up Serverless Image Handler in CloudFormation. I think we have upgraded Serverless Image Handler from v5.2.0 > v6.0.0. When we now load the website we get 500 errors from an intermittent number of images (within 'img' tags). The erroring images seem to lower over time. I.e. if we have 10 images on the page broken today, it could be 5 tomorrow.
If you copy one of these errored images you get the following:
ERRORED IMAGE
curl 'https://img2.picle.io/eyJlZGl0cyI6eyJyb3RhdGUiOm51bGwsInJlc2l6ZSI6eyJ3aWR0aCI6NjAwLCJoZWlnaHQiOjQ1MCwiZml0IjoiY292ZXIifX0sImJ1Y2tldCI6InByb2QuaW1nMi5waWNsZS5pbyIsImtleSI6ImltYWdlc1wvWW5QcDFLMkpcLzI3ZTAxOWVlLTMwY2ItNDU0ZS05ODAxLWZhMzJlOTdkYTE1OSJ9' \
-H 'authority: img2.picle.io' \
-H 'accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8' \
-H 'accept-language: en-US,en;q=0.9,nb;q=0.8,it;q=0.7,la;q=0.6' \
-H 'cache-control: no-cache' \
-H 'pragma: no-cache' \
-H 'referer: https://picle.io/' \
-H 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="102", "Google Chrome";v="102"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'sec-ch-ua-platform: "macOS"' \
-H 'sec-fetch-dest: image' \
-H 'sec-fetch-mode: no-cors' \
-H 'sec-fetch-site: same-site' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36' \
--compressed
This returns:
{"message": "Internal server error"}
But if we load the same image URL directly within a browser we get a correct 200 image:
curl 'https://img2.picle.io/eyJlZGl0cyI6eyJyb3RhdGUiOm51bGwsInJlc2l6ZSI6eyJ3aWR0aCI6NjAwLCJoZWlnaHQiOjQ1MCwiZml0IjoiY292ZXIifX0sImJ1Y2tldCI6InByb2QuaW1nMi5waWNsZS5pbyIsImtleSI6ImltYWdlc1wvWW5QcDFLMkpcLzI3ZTAxOWVlLTMwY2ItNDU0ZS05ODAxLWZhMzJlOTdkYTE1OSJ9' \
-H 'authority: img2.picle.io' \
-H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
-H 'accept-language: en-US,en;q=0.9,nb;q=0.8,it;q=0.7,la;q=0.6' \
-H 'cache-control: no-cache' \
-H 'pragma: no-cache' \
-H 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="102", "Google Chrome";v="102"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'sec-ch-ua-platform: "macOS"' \
-H 'sec-fetch-dest: document' \
-H 'sec-fetch-mode: navigate' \
-H 'sec-fetch-site: none' \
-H 'sec-fetch-user: ?1' \
-H 'upgrade-insecure-requests: 1' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36' \
--compressed
Note, after a while both the above will probably start working. I'm not sure if its an import issue, it could take a while to re-process all the images again.
I found the answer to this in this thread!:
https://github.com/aws-solutions/serverless-image-handler/issues/375#issuecomment-1227290911
tl;dr
Make sure your "concurrent Lambda executions quota" is large enough (for me was 10, increased to 1000), otherwise if you request multiple images at once, some of them will get dropped out and fail, and then CloudFront will also cache them for a few minutes.
So the fix is to request an increase of the concurrent Lambda executions quota here: https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html
Hope this fixes the issue for you as well.
P.S: btw I just noticed this Github thread is actually opened by you haha, so all credit to you! :D
Make sure to select Concurrent executions when requesting a quota increase.
I tried to create AWS Device farm remote session, which i am able to do it successfully. The response JSON of the created remote session has an endpoint (wss) and the hostAddress(IP). Rather then login into AWS device farm to interact with the device. I wanted to provide remote access directly on my own web page (I am not sure whether its possible). Hoping it can be rendered under a canvas tag.
Though i do not have experience on the socket, i just tried some sample code to connect with the received Web Socket URL.
var wsUri = "wss://devicefarm-interactive.us-west-2.amazonaws.com/?X-Amz-Date=*&X-Amz-Credential=*&X-Amz-Algorithm=*&X-Amz-SignedHeaders=host&X-Amz-Signature=*&X-Amz-Security-Token=*";
var websocket = new WebSocket(wsUri);
websocket.send('ping');
Below is the error the console.
Connection closed before receiving a handshake response.
Any sample links to implement would be helpful
I'm able to reproduce that error. I looked for examples of using the web socket connection using the networking tab after inspecting the page in chrome(since it has a web socket debugger built into it) which will show the following:
Basically how that appears to be working is it's sending us a constant stream of images.
When I copy as cURL command this is the result
curl 'wss://devicefarm-interactive.us-west-2.amazonaws.com/?X-Amz-Date=20190518T211708Z&X-Amz-Credential=ASIAIGY76PSQXN5NZ3UA%2F20190518%2Fus-west-2%2Fdevicefarm%2Faws4_request&X-Amz-Algorithm=AWS4-HMAC-SHA256&arn=arn%3Aaws%3Adevicefarm%3Aus-west-2%111122223333%3Asession%3A8f4af46d-8f86-4dcc-8324-e691ce3723f3%2F6b4dc632-188f-45b9-be32-3e9aa6881ed3%2F00000&X-Amz-SignedHeaders=host&X-Amz-Signature=39b45e1489d44dfcb904d58e59e985844416061a828aa75750d5a67db36c55dd&X-Amz-Security-Token=someTokenValue&path=video' -H 'Pragma: no-cache' -H 'Origin: https://us-west-2.console.aws.amazon.com' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.9' -H 'Sec-WebSocket-Key: 60RGfCwWuULib6NmeoC2fA==' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36' -H 'Upgrade: websocket' -H 'Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits' -H 'Cache-Control: no-cache' -H 'Connection: Upgrade' -H 'Sec-WebSocket-Version: 13' --compressed
When I did the following CLI command I get the endpoint back:
aws devicefarm get-remote-access-session --arn arn:aws:devicefarm:us-west-2:111122223333:session:8f4af46d-8f86-4dcc-8324-e691ce3723f3/6b4dc632-188f-45b9-be32-3e9aa6881ed3/00000 --region us-west-2 --query remoteAccessSession.endpoint
"wss://devicefarm-interactive.us-west-2.amazonaws.com/?X-Amz-Date=20190518T212323Z&X-Amz-Credential=ASIAIU5CA7GBP5IEBR6Q%2F20190518%2Fus-west-2%2Fdevicefarm%2Faws4_request&X-Amz-Algorithm=AWS4-HMAC-SHA256&arn=arn%3Aaws%3Adevicefarm%3Aus-west-2%3A111122223333%3Asession%3A8f4af46d-8f86-4dcc-8324-e691ce3723f3%2F6b4dc632-188f-45b9-be32-3e9aa6881ed3%2F00000&X-Amz-SignedHeaders=host&X-Amz-Signature=aaaaqaqbbbb4e9f09b7312715c295a11b77bc0d9e7b21dcb61422a61f78a1f&X-Amz-Security-Token=FQoGZXIvYXdzEFcaDD2E90%2Bsp3i%2F%2F8cBbyKDA2EGKkFYSvXDR%2Fb7LfS%2FpQEPCWFVhe9eCOTSussvshjldx69CEFvVgV3JYtOvm2yu0UMVAxlDYlujvpMfSNwLx7FH%2B42k9qGYuvy5dQbVLg%2F%2BCRuyK9OjCxpD5pUfQ9b81U6LawcI2I1CekXeTgapRuTK9tCPcGtNOlxAvWQUVlyDGTtmqjz7vRlostquMoenNr9UB1v8jx0NSo1YIlrgY8YvZV2o5pcbYiI9I9CBD0%2F3snJZAyQtmPZkMT9gr9hI0jgX1X5MlOuarFmm%2F2Sn%2FH8L3ewMQXhvuho3OTNZTISBmUgJAbZSmQcazuDmjXqPkoNpYYcUb92vd2w5MbRfFSa5SHHXUMVcE5Wsop3BzwJyj%2FNyl59BdjFWdo82NgSFP6OBjYLjiux3hR2dx86ILJ9tfNMNfq0WXzL3Z%2BqecwMTxlxrLfZmPftsUDaO5RPtOP9uuI%2BPjfIOWOV7uFy9GjKG4HKFY%2BZVGgWhb1fVVG7%2BYHbPxgMaAKI3YJqmM9IIy8%2FdCjL74HnBQ%3D%3D%7CMjA1LjI1MS4yMzMuMTc5"
which appears to be signed. Using wscat I tried to connect to it.
endpoint=$(aws devicefarm get-remote-access-session --arn arn:aws:devicefarm:us-west-2:111122223333:session:8f4af46d-8f86-4dcc-8324-e691ce3723f3/6b4dc632-188f-45b9-be32-3e9aa6881ed3/00000 --region us-west-2 --query remoteAccessSession.endpoint)
wscat -c $endpoint
Error:
/usr/local/lib/node_modules/wscat/node_modules/ws/lib/websocket.js:455
throw new Error(Invalid URL: ${this.url});
I'll need to spend some more time on this later but I think some of this content is helpful so I posted it.
I am using WSO2 IOT server with raspberrypi 3. I am in the beginning level. I was able to switch on/off the LED bulb which is connected to raspberrypi with this command.
curl -k -X POST "https://172.16.13.86:8243/raspberrypi/1.0.0/device/us310v497by0/bulb?state=on" -H "accept: application/json" -H "Authorization: Bearer 739e2223-62b6-3a24-890f-5b6e610ed6d2"
Now I want to get the current temperature which is detected by the dht11 sensor. I want to know a same type of command which I used for switch on/off the LED bulb. Can anyone help me please?
Please try:
curl -X GET --header 'Accept: application/json' 'https://ServerIP:9443/api/device-mgt/v1.0/events/last-known/deviceType/deviceId' -H "Authorization: Bearer token"
I have a restful API created using Flask and Flask-Restful. Everything works fine using the development server. All routes are in a Blueprint, though the particular route we're dealing with here is not a Flask-Restful one. It's just a normal Flask route.
I am also using Flask-CORS.
To deploy, everything is dockerized and I'm using CherryPy as the WSGI host. So a CherryPy app hosts the Flask app in a container.
I'm using Traefik as a reverse proxy in another container.
If I make the following request in Chrome by pasting the URL in, the GET request works:
https://api.my-app.new/api/admin/user?_end=10&_order=DESC&_sort=id&_start=0
However, if I attemtp to make the same GET request from a React app, an OPTIONS preflight request is made and it is failing with a 404.
I've traced through it as best I can in PyCharm and the problem seems to be in the following code in Flask's app.py:
def preprocess_request(self):
bp = _request_ctx_stack.top.request.blueprint
Basically, the blueprint is not found.
What is actually getting sent is seen in this curl call:
curl 'https://api.my-app.new/api/admin/user?_end=10&_order=DESC&_sort=id&_start=0' \
-X OPTIONS -H 'access-control-request-method: GET' -H 'origin: https://admin.my-app.new' \
-H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36' \
-H 'accept: */*' -H 'referer: https://admin.my-app.new/' -H 'authority: api.my-app.new' \
-H 'access-control-request-headers: authorization,content-type' --compressed
And if I print out the headers received by the Flask-app (in #app.before_request), I get the following:
[2018-01-25 04:31:48,438] INFO - X-Forwarded-Server: cb5d56692c6d
Referer: https://admin.my-app.new/
Accept-Language: en-US,en;q=0.9
Origin: https://admin.my-app.new
X-Real-Ip: 172.19.0.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Access-Control-Request-Headers: authorization,content-type
X-Forwarded-Proto: https
Host: api.my-app.new
Accept: */*
Access-Control-Request-Method: GET
X-Forwarded-Host: api.my-app.new
X-Forwarded-For: 172.19.0.1
X-Forwarded-Port: 443
Accept-Encoding: gzip, deflate, br
[2018-01-25 04:31:48,440] INFO - Error 404:/api/admin/user?_end=10&_order=DESC&_sort=id&_start=0: 404 Not Found: The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again. ("/app/app/routes.py:87")
Now, if I make the same request with the app running without the traefik reverse proxy, it works. The only thing that is different in the curl
request is that I'm using http, instead of https.
Here are the headers that Flask receives in this case:
[2018-01-24 21:43:43,199] INFO - Referer: https://admin.my-app.new/
Origin: https://admin.my-app.new
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Authority: api.my-app.new
Access-Control-Request-Headers: authorization,content-type
Host: api.my-app.new:8000
Accept: */*
Access-Control-Request-Method: GET
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
[24/Jan/2018 21:43:43] "OPTIONS /api/admin/user?_end=10&_order=DESC&_sort=id&_start=0 HTTP/1.1" 200 -
I figure that there is something wrong with the headers or something that is confusing Flask. I saw another post from 2014 that mentioned needing the SERVER_NAME, but that didn't help.
Finally, I had originally used NGinx as a reserve proxy and had gotten everything working. One of the the things
that was hard to get working with NGinx was redirects and OPTION requests. I did get it working after madly chasing down various blog
posts, but as I look back on it as I right this, I notice a curious thing: I wound up writing script in nginx.conf
to automatically return 200 for all OPTIONS requests!
Any idea why the OPTION requests are failing?
As webKnjaZ notes: "It's a bug."
After digging in deeper, I discovered that the problem that Flask was getting different URL for the GET request than for the OPTIONS request, and that if CherryPy was removed the problem went away. That led me to this CherryPy issue which describes my situation exactly.
https://github.com/cherrypy/cherrypy/issues/1662
The author noted that the bug appeared when moving from CherryPy 11 to 12 (I was on 13.x) so I tried downgrading to 11.0.0 and that fixed it.