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.
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 have hosted my web-app on "Firebase Hosting" on my own custom domain for eg:- webapp.example.com. I have enabled CORS so that browser wont block it.
My REST services are hosted on another sub-domain eg:- api.example.com
Now when I am calling API from my web-app it says "Failed to load response" and fails.
Status code is 200 though.
Response Headers:
Access-Control-Allow-Headers: Origin,X-Requested-With,Content-Type,Accept
Access-Control-Allow-Methods: POST,GET,PUT,OPTIONS,DELETE,PATCH
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 3600
Allow: GET, HEAD, POST, TRACE, OPTIONS
Connection: close
Content-Length: 0
Date: Sun, 28 Apr 2019 09:37:30 GMT
Server: Apache-Coyote/1.1
Request Headers
Access-Control-Request-Headers: content-type,x-referral
Access-Control-Request-Method: GET
Origin: https://webapp.example.com
Referer: https://webapp.example.com/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
Any idea why this is happening or how should I fix it.
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 am writing a restful API and try to use all available http method but have a problem with PUT method.
When I send http request whith put method, I have "400 Bad request" error.
If I use POST method, I have no problem.
Here is my http PUT request :
Remote Address:::1:8080
Request URL:http://localhost:8080/adminRight
Request Method:PUT
Status Code:400 Mauvaise Requête
Request Headersview parsed
PUT /adminRight HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 37
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
Origin: chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: JSESSIONID=41D1CCDF94D3150F0FCA3754E347A4AD
Request Payload
typeList=1&id=2&nom=labelViewerAvance
Response Headersview parsed
HTTP/1.1 400 Mauvaise Requête
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 984
Date: Fri, 30 May 2014 12:55:32 GMT
Connection: close
And here my http POST request :
Remote Address:::1:8080
Request URL:http://localhost:8080/adminRight
Request Method:POST
Status Code:200 OK
Request Headersview parsed
POST /adminRight HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 37
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
Origin: chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: JSESSIONID=41D1CCDF94D3150F0FCA3754E347A4AD
Request Payload
typeList=1&id=2&nom=labelViewerAvance
Response Headersview parsed
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=utf-8
Content-Length: 2
Date: Fri, 30 May 2014 13:09:03 GMT
What is the difference between PUT and POST syntax? Or maybe, is it one special configuration in my web.xml?
Thanks in advance for your help.
Edit with new information :
My requests are mapped in java with these two methods :
#RequestMapping(value = "/adminRight",
method = RequestMethod.PUT
)
#ResponseBody
public ResponseEntity<String> updateListRights(#RequestParam(value = "typeList") String typeList,
#RequestParam(value = "id") String idList,
#RequestParam(value = "nom") String nomList)
{
and
#RequestMapping(value = "/adminRight",
method = RequestMethod.POST
)
#ResponseBody
public ResponseEntity<String> addNewListRights(#RequestParam(value = "typeList") String typeList,
#RequestParam(value = "id") String idList,
#RequestParam(value = "nom") String nomList)
{
Your Server: Apache-Coyote/1.1 is just a HTTP connector. Behind that connector there is a web server, for example Apache Tomcat. You have to look up the manual of that server and check how you can allow a HTTP method. By Tomcat there is a server.xml file, in that there is something like this:
// Sample Security Constraint
<security-constraint>
<web-resource-collection>
<web-resource-name><strong>restricted methods</strong></web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint />
</security-constraint>
You should add PUT and DELETE to that list. If your REST clients are running in browsers and they are served under a different domain, then you have to enable the OPTIONS method either (for CORS preflight requests), and add CORS allow headers as well. By serving browsers you have to add some HTTP response headers as well and set them properly to prevent XSS attacks.
Another security concern that you should hide the version number of the coyote connector.
Btw. using session cookies like Cookie: JSESSIONID=41D1CCDF94D3150F0FCA3754E347A4AD is not RESTful.
I know very little about java request mapping, but by REST you use POST usually to add a new item resource to a collection resource, for example POST /rights in your case, and PUT usually to edit an entire item resource, for example PUT /rights/{id} where {id} should be a unique resource id (probably the same as one of your aggregate ids). In your code I can't see anything related to this URL structure by the PUT request. You may be interested in PATCH as well.
I have two possible flows:
ConsoleClient -(1)-> ApplicationServer
or
SilverlightClient -(2)-> WebServer -(3)-> ApplicationServer
Fiddler successfully captures the HTTP traffic on the (1) and the (2), but not on the (3). Here is a sample capture on (1):
POST /WcfDemo/ws HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Host: il-mark-lt
Content-Length: 521
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">http://tempuri.org/IWcfDemoService/Add</a:Action><a:MessageID>urn:uuid:d7fde351-12fd-4872-bc26-52ff97f126e9</a:MessageID><a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo><a:To s:mustUnderstand="1">http://il-mark-lt/WcfDemo/ws</a:To></s:Header><s:Body><Add xmlns="http://tempuri.org/"><x>4</x><y>5</y></Add></s:Body></s:Envelope>
HTTP/1.1 200 OK
Content-Length: 399
Content-Type: application/soap+xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 17 Sep 2011 20:57:16 GMT
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">http://tempuri.org/IWcfDemoService/AddResponse</a:Action><a:RelatesTo>urn:uuid:d7fde351-12fd-4872-bc26-52ff97f126e9</a:RelatesTo></s:Header><s:Body><AddResponse xmlns="http://tempuri.org/"><AddResult>9</AddResult></AddResponse></s:Body></s:Envelope>
And here is an example of (2):
POST /WcfDemoService.svc/ws HTTP/1.1
Host: localhost:56970
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.6,he-IL;q=0.5,he;q=0.4,ru-RU;q=0.3,ru;q=0.1
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://localhost:56970/ClientBin/SilverlightClient.xap
Content-Length: 581
Content-Type: application/soap+xml; charset=utf-8
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope"><s:Header><a:Action s:mustUnderstand="1">http://tempuri.org/IWcfDemoService2/Add</a:Action><a:MessageID>urn:uuid:e8420d3e-f568-49ce-bfc7-5631d5bf3fd0</a:MessageID><a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo><a:To s:mustUnderstand="1">http://localhost:56970/WcfDemoService.svc/ws</a:To></s:Header><s:Body><Add xmlns="http://tempuri.org/"><x>11</x><y>22</y><serverChannelKind>ws</serverChannelKind></Add></s:Body></s:Envelope>
HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Sat, 17 Sep 2011 20:59:23 GMT
X-AspNet-Version: 4.0.30319
Content-Length: 401
Cache-Control: private
Content-Type: application/soap+xml; charset=utf-8
Connection: Close
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">http://tempuri.org/IWcfDemoService2/AddResponse</a:Action><a:RelatesTo>urn:uuid:e8420d3e-f568-49ce-bfc7-5631d5bf3fd0</a:RelatesTo></s:Header><s:Body><AddResponse xmlns="http://tempuri.org/"><AddResult>33</AddResult></AddResponse></s:Body></s:Envelope>
Now, I am absolutely sure the (3) does get through. So, it all boils down to some misconfiguration on the WebServer, but I cannot nail it. The Web server is just a trivial ASP.NET application hosted within IIS. It even has the following lines in the web.config:
<system.net>
<defaultProxy>
<proxy bypassonlocal="false" usesystemdefault="true" />
</defaultProxy>
</system.net>
Still, this does not work.
To further strengthen my suspicion on the web server configuration, I have checked the SilverlightClient --> ApplicationServer flow and it is captured just fine.
I am using the Asp.Net development server.
Edit
Running procmon reveals that the following suspicious registry key is consulted (amongst others):
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProxyBypass
And on my machine it was set to 1. I have changed it to 0 and seems like it solved my issue. The only problem is that when I change it back to 1 Fiddler continues to capture the problematic leg! Very interesting.
Anyway, I am satisfied, for now.
You are calling "localhost" right?
Fiddler is not able to capture the local traffic if you are using "localhost" as hostname.
Solutions:
Use servername (e.g. myserver)
Use ip4.fiddler (e.g. http://ipv4.fiddler:8787)
Not sure if these are causing it ... but,
A few things to check:
In IIS7 the appPool has a loadUserProfile setting. It causes the session to load a user profile which means it can get system proxy settings.
Check the code making the request from the webServer - even if you configure to use the system proxy and bypass onLocal (which only applies to names without dots in it), code making the request can still explicitly set to use or not to use a proxy.
Far fetched but you may want to play with the account the appPool runs as - local account with profile vs. Network Service.
Hope that helps - these network things have a lot of variables between two points :)