My rest service url's are not working in page load and a

Hi Ram,

One possible problem I can think of is the CORS (Cross Origin Region Support). Can you please enable CORS filters in the webserver (where the application is hosted).

Also, can you please check for the respective problem (or information) in the browser through 'Firebug' or 'Web Inspector'

Hope this helps.

Thanks and Regards,

Anil Kumar.

But I am using .net rest services here, how can i achieve this.

It may help for you to explain our environment more fully.

The answers to this thread are saying that this looks like a CORS issue.  CORS (or Cross-Origin Resource Sharing) is a common issue (see Wikipedia) where modern browsers have added 'security' features to prevent security intrusion attacks via web pages.  The short summary is that if the 'main' page in a web app comes from one URL, then the JavaScript run on that page can't point to resources loaded from another URL  (You can't unintensionally have a page at one ORIGIN getting resources CROSS-reference RESOURCES from another URL/a second "ORIGIN").

There are three ways to solve this:

1. You can disable the CORS checks in your browser, but while that may work for one client, it does not help you build a web application that anyone can use.

2. You can add a proxy (pass-through) on the application web server that takes all the requests and then on the server side calls the REST service as a server-server interaction.

3. MOST COMMONLY, you can tell the Web Server serviing up the web application to inform the browser that it is OK to go to particular known cross-origin resources.    (This is what the previous post was suggesting).

It would be useful to know:

- where (what web server) is serving up the Web Application (the HTML and JavaScript files that compose the main app)....  I am assuming that this is a Tomcat running in your PDSOE environment.

- where the REST services are running (normally, for OE Services, these deploy the .paar file on the same server, but you are talking about  -- I assume these are your .net REST services.

There are lots of hits on Google for ".net rest service CORS"

This provides a few suggestions:

stackoverflow.com/.../cross-origin-resource-sharing-for-c-sharp-wcf-restful-web-service-hosted-as-wind

I am added CORS filter to my .net rest services. Still I am unable to get response from mobile events.

We might need to debug the request flow. Were you able to fire a successful request to your REST Service from a external client.

To narrow down the problem, can you please try calling your REST Service with and without a Mobile Application and see what you get in your tomcat access logs.

When i debug using firebug it is showing an error  "Blocked loading mixed active content "202.63.113.99/.../getdata" "

Please give some suggestions how to solve this error.

Ram,

I just wrote a simple sample with the same data-source you had (sofuture.com/.../iphone) and it did not work for me either.  The reason it did not work for me was because of CORS.

After that, I went into my Chrome icon and edited and added a parameter:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security

That disabled Chrome's CORS check and I run it again.  It worked on the second time ...

Do you have Chrome, can you add that parameter to your Chrome and test it again? If it works, it will confirm that you have a CORS issue.  Another way to confirm is by right clicking on your Mobile App (on the Chrome Browser), select "Inspect Element" and look at errors on the Console Tab.

Hope this helps you,

Ricardo Perdigao

WRT: "I am added CORS filter to my .net rest services. Still I am unable to get response from mobile events."

You should be doing this on the Tomcat serving up the OpenEdge pieces.    Did you enable it on the .NET side?

Bill,

His data is coming from a .NET REST Service and he is most likely running this on the cloud - mobile.progress.com (completely independent from OE Tomcat & backend).  

So, to me, it makes sense that he is authorizing another origin on his .Net Rest Service.  For that, he should be doing something like this:

www.asp.net/.../enabling-cross-origin-requests-in-web-api

The challenge here is identifying the correct domain that is making the request (so you can authorize it) ... I think it should be mobile.progress.com, but I don't know for sure.

Hope this helps,

Ricardo

For it work from the OE Mobile Cloud development, the origin he should authorize is "project.mobile.progress.com/".  On production, he will need to authorize his domain name.

Hi Ricardo,

          You are correct, I am calling  my .net rest service from mobile.progress.com mobile page events.

I was able to bypass the first CORS issue by using jsonp (see picture above).  But than I hit another issue.  Progress OE Mobile Website uses https and your service is on http. You cannot mix and match http and https because of CORS.  Either the request and response are http or https. It would not be a problem on production, but it is one for your Development environment. 

I will ask Edsel Garcia to check this thread out ... He is the God on all things REST. 

Hi Ricardo Perdiga,

                    Any updates from  Edsel Garcia about this thread.

Hi

This espn url is working fine." api.espn.com/.../sports ,I am able get data from this url. So what's wrong in my .net rest servcie url " sofuture.com/.../iphone"

Hello,

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.

Hi  egarcia

 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="*" />

Iamrams4u,

Something is wrong with you how your .Net service implement CORS.  Here is a Website that you can use to test your service CORS:

test-cors.org

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?

Warm Regards,

Ricardo Perdigao

iamrams4u,

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:

      log4j.logger.com.progress.rest.security=ERROR, xxxxxxxx

.  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.

Michael,

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?

Thanks

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?

Hello,

The following links might be useful:
- http://enable-cors.org/server_iis7.html
- http://stackoverflow.com/questions/12458444/enabling-cross-origin-resource-sharing-on-iis7

I hope this helps.

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.

Luck!

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...

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!