My rest service url's are not working in page load and any other events. Here is my sample url I am using " http://sofuture.com/tiservices/tracefamily/AuthService.svc/Version/tracefamily/iphone".
While click on test button it is giving response, but calling from page load events in opendege mobile screens it is not working.
Please do this needful help.
Nothing I change seems to make any difference. It must be something to do with running in the browser, because if I deploy the app to my phone, it works on there. I give up!
Good help has already been posted in this thread: references to CORS, workarounds for CORS issues and the issue with mixed URI scheme: http vs https.
I talked to Ricardo Perdigao yesterday and tried to post but there was an issue with the post going through.
I think that the two main factors are the following:
- REST service does not return an Access-Control-Allow-Origin (your email from this morning confirms - see screenshots below)
- Issues loading HTTP content from HTTPS site (Mobile App Builder).
I also noticed that the REST service internally uses JQuery $.ajax() API which seems to fail when loading data from HTTP from HTTPS site. (This behavior does not seem to happen with the JSDO Services ...)
A possible way to solve this issue is to remove some of the factors:
- Add Access-Control-Allow-Origin header. See enable-cors.org/server_aspnet.html or link that Ricardo Perdigao provided above. (The http://enable-cors.org/ we site provides good information CORS.)
- To avoid the issue when loading mixed content (HTTP/HTTPS), you could run the app from Progress Developer Studio which will then copy the HTML/JS/CSS of the app and serve it using HTTP in the Tomcat in the box.
- Another alternative, is to have the app hosted on the same server as the REST service.
In this scenario, both the CORS and HTTP/HTTPS issue would not occur since it the same server.
The difference between the services that you are testing "sofuture" and "espn" is that the "espn" includes and Access-Control-Allow-Origin header.
Please notice the response headers in the attached screenshots.
Once that you add the header to your service then it should work.
I hope this helps.
I am addded Access-Control-Allow-Origin value to my rest services like bellow. Still my problem not solved.
<add name="Access-Control-Allow-Origin" value="*" />
Something is wrong with you how your .Net service implement CORS. Here is a Website that you can use to test your service CORS:
If you place the ESPN on the Remote URL and "Send Request" you will see that CORS headers are properly implemented on that service. If you post your URL on the Remote URL and "Send Request" you will see that the headers from your REST Service does not support the CORS headers.
Unfortunately this is the limit on my knowledge. Maybe you could look for help on the .Net side to get you Service to be CORS compliant?
Did you ever get this working? I am having the same problem. I tried enabling CORS filters on both the web server hosting the REST services and the tomcat server serving up the mobile application, but it doesn't seem to have made any difference.
The REST service's CORS filter has debugging information available. To enable the security service's debug logging do:
. in the web application's logging configuration file ( .../webapps/<rest-service-name>/WEB-INF/classes/log4j.properties)
change the logging level for this lines logging level from ERROR to DEBUG:
. restart the web server for the change in logging level to take effect
. The logging will appear in the REST service's log file located under .../webapps/<rest-service-name>/WEB-INF/adapters/logs
Look for lines that include "CORS". If you don't see anything in the log, it is likely that your client never negotiated CORS access with the REST service.
Hope this helps.
Thanks for that. But I'm reusing the REST services from a previous Silverlight app. They're hosted on an IIS7 server. Do you know how to enable CORS filter debugging in IIS?
Aha! I've been digging in the standard IIS log file. The request seems to be reaching the server, but the verb is 'OPTIONS', not 'POST'. What am I doing wrong?
Sorry John, thought you were working against an OpenEdge REST service.
The OPTIONS verb is used by a REST client during a CORS preflight request. When a REST client determines that it is being asked to access a RESTful resource in a domain different from where the current page originated from, it interrupts the request and initiates a CORS preflight request. You basically have no control over the client's CORS support.
The client initiated preflight request uses the OPTIONS verb to send a set of client request information to the server, which then compares that formation with its CORS configuration to determine whether the client should be granted access or not. The server returns a success if the request is granted along with a description of what the client may and may not do. The client uses the server's response to know whether to discontinue the original request or to continue its execution.
For example: if your client issues a POST and you see in the server log the OPTIONS request, you know that the client initiated the CORS preflight request. If the OPTIONS request is not followed by the POST, you can probably assume the server denied the CORS request and try to find out why from the server's logs. If you see your POST request following the OPTIONS, you can assume the CORS preflight was granted and your client has access. When the client is granted access you can see in the OPTIONS response which verbs and headers the client can use.
Perhaps this brief description of a CORS protected server resource will help in your IIS debugging.
Thanks for the explanation. That makes sense.
For what it's worth, I now have a working solution. I ticked the 'Enable Echo' box in my service and I get data back now. I can't claim to understand why. What does 'Enable Echo' mean? Does it have the effect that the client doesn't issue a pre-flight OPTIONS request? Also, the POST request doesn't appear in the IIS log (and neither does anything else). But I'm definitely getting data back, so I'm just going to carry on and not worry about it.
Thanks for all your help, everybody.
Nope, it's not coming from the server at all - that's why there's nothing in the IIS log. Back to the drawing board...