I am switching over from Flash to HTML5, and I am having trouble connecting my socket over from the browser in HTML5 to Node.js.
For example, I get this error in the Firefox debugger:
The connection to ws://127.0.0.1:2500/ was interrupted while the page was loading.
Firefox can’t establish a connection to the server at ws://127.0.0.1:2500/.
In Haxe, I am using the import: flash.net.Socket;
It seems to attempt to connect to the Node.js server, however the data I am receiving is not what I want:
GET / HTTP/1.1
Host: 127.0.0.1:2500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
The above is from the Node.js server.
Also, the event listener EVENT.Connect is not being called since no connection is happening.
Any suggestions? Is there a way to connect to a Node.js server in HTML5 with Haxe? I am using Haxe just for the sockets, I am not creating a server in Haxe.
Related
I'm trying to develop with universal deep links. When the user has the Uber app installed, everything works as expected. But if not, the user ends up at a page with "Open in the Uber app" and "Download Uber" links, both of which do nothing. In the console, a CORS error is reported. This includes opening the "example universal deep link to Uber HQ" given in the developer docs. Is this a known issue or is there something I can do to work around it? I'd like my users to be able to use the deep link without this poor experience.
Request headers (for ul-min.a36a5e.js):
GET /web-mobile-client/js/ul-min.a36a5e.js HTTP/1.1
Host: d34odocr7rsfu1.cloudfront.net
Connection: keep-alive
Origin: https://m.uber.com
Sec-Fetch-Dest: script
User-Agent: Mozilla/5.0 (Linux; Android 8.0.0; Moto Z (2)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.99 Mobile Safari/537.36
Accept: */*
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Referer: https://m.uber.com/ul/?action=setPickup&pickup=my_location&dropoff%5Bformatted_address%5D=Uber%20HQ%2C%20Market%20Street%2C%20San%20Francisco%2C%20CA%2C%20USA&dropoff%5Blatitude%5D=37.775231&dropoff%5Blongitude%5D=-122.417528&_ga=2.28187893.830846417.1581952272-1919070024.1581952272
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,ja;q=0.8
Response Headers
HTTP/1.1 403 Forbidden
Content-Type: application/xml
Transfer-Encoding: chunked
Connection: keep-alive
Date: Tue, 18 Feb 2020 17:29:53 GMT
Server: AmazonS3
X-Cache: Error from cloudfront
Via: 1.1 c66a9c8f31dcbd61d052f66d50b6d87c.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: LAX3-C1
X-Amz-Cf-Id: 00Y21qP41BPYaywzR6BHA0BC-5ctAe03xFKBgOBgDKupwlaN-2IzLA==
I am getting a weird behavior from Chrome, which I was not recently getting. A week ago, my project was making proper CORS requests to my REST api (Java spring) and all was fine. But yesterday, Chrome (59.0.3071.115) is no longer sending the JSESSIONID as it used to. It now sends a io cookie in its place. That io cookie seems related to WebSocket in some way, which I am not making use of in any of my code.
The thing is, when I try the same code on Edge browser, everything is fine. Edge does send my JSESSIONID cookie and no "io" cookie is sent.
Anyone has experienced this before?
Here is my setup and an example of a request on both browsers.
Setup:
OS: Windows 10
SPA: React, AXIOS (0.16.2)
REST: Java, Spring boot, Tomcat (Embedded)
AXIOS configuration
function getNewAxiosInstance() {
//Init our instance
const ax = axios.create();
//Config defaults
ax.defaults.baseURL = rootUri;
ax.defaults.timeout = 1000;
ax.defaults.withCredentials = true;
return ax;
}
Chrome request
Request URL:http://localhost:8080/api/2.0/client/service_orders/_activeState
Request Method:GET
Status Code:200
Remote Address:[::1]:8080
Referrer Policy:no-referrer-when-downgrade
Response Headers
view source
Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://localhost:3000
Content-Type:application/json;charset=UTF-8
Date:Sun, 16 Jul 2017 13:58:39 GMT
Set-Cookie:JSESSIONID=6DA824C819AB48051DC6A63367010DDA;path=/;HttpOnly
Transfer-Encoding:chunked
Vary:Origin
Request Headers
view source
Accept:application/json, text/plain, */*
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8,fr-CA;q=0.6,fr;q=0.4
Cache-Control:no-cache
Connection:keep-alive
Cookie:io=T6umtNN53FTADnx1AAAA
Host:localhost:8080
Origin:http://localhost:3000
Pragma:no-cache
Referer:http://localhost:3000/
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Edge request
Request URL: http://localhost:8080/api/2.0/reception/service-orders/_activeState
Request Method: GET
Status Code: 200 /
- Request Headers
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-CA
Connection: Keep-Alive
Cookie: JSESSIONID=177FD4191C578793F8BC04D9DB7287A5
Host: localhost:8080
Origin: http://localhost:3000
Referer: http://localhost:3000/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15063
- Response Headers
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:3000
Content-Type: application/json; charset=UTF-8
Date: Sun, 16 Jul 2017 14:08:26 GMT
Transfer-Encoding: chunked
Vary: Origin
Oh well,
There was indeed something fishy with Chrome. I just reinstalled Chrome from scratch and all is good.
Don't know what happened with Chrome, as I did not install any new extensions nor did I changed any settings.
Cheers
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?
Magento's 1.9 REST API needs both Authorization Header and oauth query params, but oauth() only allows for either OAuthSignature.HEADER, or QUERY_STRING
given().auth().oauth(CONSUMER_KEY, CONSUMER_SECRET, ACCESS_TOKEN,
SECRET_TOKEN,OAuthSignature.HEADER)
I tracked the code down to com.jayway.restassured.internal.httpAuthConfig.process(..), but I am not sure what to do from here.
Q: Is there a filter or some method that would allow me to force both?
TL;DR
I started by referring to this: How to use POSTMAN rest client with magento REST api with Oauth. How to get Token and Token Secret?
The last statement
Note, you must check the "Add params to header" checkbox in order for Magento REST calls to work properly.
Using Postman, OAuth 1.0 GET works when I check the box and fails
when I don't, with 403 access denied. This is the same response I get when I use OAuthSignature.QUERY_STRING in rest-assured.
WORKS: Sent from Postman (add params to header)
GET /api/rest/products?oauth_consumer_key=<my-consumer-key>&oauth_token=<my-oauth-token>&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1471929347&oauth_nonce=LJ3o2K&oauth_version=1.0&oauth_signature=0Any8rQ+XjbnWcdXmpHFujg1V7o= HTTP/1.1
Host: dockerized-magento.local
Connection: keep-alive
Authorization: OAuth oauth_consumer_key="<my-consumer-key>",oauth_token="<my-oauth-token>",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1471996573",oauth_nonce="ElK9Fx",oauth_version="1.0",oauth_signature="SvDfMxrWj1O0P2%2FWPOomEVEb93c%3D"
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
Postman-Token: 9348e805-3c6f-54d7-082f-a1458164725d
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
rest-assured OAuthSignature.QUERY_STRING
Doesn't Work: OAuthSignature.QUERY_STRING
GET /api/rest/products?oauth_nonce=-316324336&oauth_signature=TlANZu5ogxowYJCpr2V7W448tjw%3D&oauth_token=<my-oauth-token>&oauth_consumer_key=<my-consumer-key>&oauth_timestamp=1471996938&oauth_signature_method=HMAC-SHA1&oauth_version=1.0 HTTP/1.1
Accept: */*
Content-Length: 0
Host: dockerized-magento.local
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.1 (Java/1.8.0_77)
Accept-Encoding: gzip,deflate
RESP: {"messages":{"error":[{"code":403,"message":"Access denied"}]}}
Same failed response using Postman with out "add params to header")
Doesn'T WORK: Sent from Postman (NO - add params to header)
GET /api/rest/products?oauth_consumer_key=<my-consumer-key>&oauth_token=<my-oauth-token>&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1471976516&oauth_nonce=OTWTNW&oauth_version=1.0&oauth_signature=Dsh5TEErEC9rMbKakta1v2E7ZTw= HTTP/1.1
Host: dockerized-magento.local
Connection: keep-alive
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
Postman-Token: f9800e1c-b259-f025-cf48-68e483283869
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Response: {"messages":{"error":[{"code":403,"message":"Access denied"}]}}
Mistake made, HEADER option works fine.
The Postman link above, which works fine and was a great help, led me to believe I needed both url params and headers. I went back to postman and deleted the url params after adding params to headers. This worked fine.
I went back and found my consumer keys were wrong.
Tip: Magento Consumer Keys and Secret are not "copyable", use firebug!
I am new to REST so bear with me if I'm missing something obvious.
Any pointer would be much appreciated as I am a bit lost.
Scenario
I needed to post some data to the following REST service: https://api.dotmailer.com/ from my web application https://myapp.com/.
During testing, I was able to post the data from my local pc.
However, as soon as I published the updated application to https://myapp.com/ on a remote server, I was no longer able to post any data.
What I've tried so far
Added rule to the remote server firewall to allow outgoing traffic to use https. Didn't solve the problem.
Disabled the url rewriting rule that change http to https for myapp.com. Didn't solve the problem.
Pasted the URL I use to post my data (https://api.dotmailer.com/v2/address-books/12345/contacts) in a browser on the remote server, entered the correct credentials, but couldn't access it.
the error message said "Unable to open this internet site. The requested site is either unavailable or cannot be found." If I do the same on my local PC I can access the URL.
Monitored the two calls with Fiddler2.
I include the results of the monitoring process below:
CALLS MADE FROM REMOTE SERVER
----------
POST /bla.aspx HTTP/1.1
Host: myapp.com
Connection: keep-alive
Content-Length: 10660
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: https://myapp.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: https://myapp.com/bla.aspx
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,it;q=0.6
Cookie: ASP.NET_SessionId=xxx; Myapp=xxx; GUID=xxx
CALLS MADE FROM LOCAL PC
----------
POST /bla.aspx HTTP/1.1
Host: localhost:xxx
Connection: keep-alive
Content-Length: 10656
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:60675
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: http://localhost:xxx/bla.aspx
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,it;q=0.6
Cookie: __eqtUser=xxx; ASP.NET_SessionId=xxx; Myapp=xxx; GUID=xxx
Question
I believe point 3 shows that the cause is some setting on the remote server.
Does anyone know what it could be? Or am I completely off-track?
Update
I spoke with the developer on the receiving end of my calls who can monitor incoming traffic.
He could see my local calls but not the ones submitted from https://myapp.com.
In response to gmlime reply, I've added the following to myapp.com web.config file but didn't help.
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
Should I put it at a higher level in the hierarchy?
Make sure that this gets added to the response:
YourAddHeaderMethod("Access-Control-Allow-Origin", "*");
Many servers deny posting from other domains and can terminate the connection. You can learn more about it from the w3 docs for Access-Conrol-Allow-Origin and Mozzilla covers some scenarios. You may have to check with the server administrator to rule out cross domain problems also.