Re: Header set Access-Control-Allow-Origin for web services -- WEB400

Good question, it depends on what you're struggling with but, as a long time RPG programmer I have been through the pain you currently find yourself in, so I will do my best to explain if I can.

If I understand your case correctly you have two servers running on your IBM i:

http://i.server.com:10000/web/services/Oceans which is your experimental web service
http://i.server.com:80/ which is your web server serving up your HTML/Javascript pages (I've assumed port 80)

When you visit your website (port 80), it serves up some HTML and Javascript, which attempts to make an AJAX request back to the web service (port 10000), but this is not allowed because the AJAX request is not to the same origin (the port is different), so you get an error. The trick is to hide your web service behind the web server so that both your web pages and your web service appear to be hosted at the same place, you can do this by configuring certain paths on your web server to reverse proxy requests to the web service. The basic concept of reverse proxying is fairly simple to understand, it's just the web server saying "I don't know how to handle this URL, but I know someone who does so I'll forward it there and send you back the result when I get it". So, you might set-up the following path on the web server (port 80) to proxy to the web service (notice you can map any path on the web server to any URL):

/webservice/oceans --> http://localhost:10000/web/services/Oceans

Now any request you make to the following address http://i.server.com:80/webservice/oceans will be forwarded to the web service on the same server on port 10000 (you can test this with the browser). This includes any children of that path, so:

http://i.server.com:80/webservice/oceans/customers ----forwards to----> http://i.server.com:10000/web/services/Oceans/customers
http://i.server.com:80/webservice/oceans/customers/1/orders/3 ----forwards to----> http://i.server.com:10000/web/services/Oceans/customers/1/orders/3
etc.

Now, you need to change your Javascript too because this will still have the full URL of the web service in the address and thus be still pointing to port 10000, so the above changes will not have yet made any difference. Instead of using absolute URLs in your AJAX requests (e.g. GET http://i.server.com:10000/web/services/Oceans/customers/1) you need to use relative URLs that point to the path you have mapped above (e.g. GET /webservices/Oceans/customers/1). Now your AJAX requests go back to the same server that served up the page they are embedded in so the same origin policy is respected, the web server sees the path /webservice/oceans and says "Ah, I have to forward this request to http://i.server.com:10000/web/services/Oceans/ and then when I get a result, send it back").

Setting it up on the IBM I HTTP server is quite easy, go to the admin panel at http://i.server.com:2001/HTTPAdmin and log in (you need *ALLOBJ or to be added to authority table to do this). Make sure you select your *web* server and then go to the "proxy" option in the left menu. When you get there, click the "Reverse Proxy" tab and make sure "Reverse proxy capabilities" is Enabled. Then, under "Proxy requests to remote servers:" add your mapping (for example):

"Client requests" "/webservice/oceans" "localhost:10000/web/services/Oceans"

save, apply and then restart the server.

Now, pointing your broswer at http://i.server.com:80/webservice/oceans/<web-service> should give you back something from your web service.

Tim.

________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Booth Martin <booth@xxxxxxxxxxxx>
Sent: 06 December 2018 19:19
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Header set Access-Control-Allow-Origin for web services

Is there a place that uses explanations and examples that would be
meaningful to an RPG programmer (The Target Audience for the IWS Wizard)?

On 12/6/2018 3:59 AM, Tim Fathers wrote:

If your web server is on a different port than your web service then it will also fail the "same-origin" policy test (see here https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSame-origin_policy&data=02%7C01%7C%7C201d982fc0d241d062ef08d65ba7590a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636797171638615991&sdata=NQyYumnXM%2BcQuEX10yebavKNVLAOfjNEd1EuZln14Os%3D&reserved=0).

As I mentioned before, IMO you are better not to mess around with CORS but to forward proxy the web app requests from the HTTP server to the web service. In other words, set-up a forward proxy rule in your web server that says

/web/services ---> localhost:10000/web/services/Oceans

...then change your AJAX requests to be relative to the current host e.g. "/web/services/Oceans/get....". Because these requests are to the same origin you won't fall foul of the same origin policy and your web server will make sure the request gets routed to your Oceans application server.

Tim.

Same-origin policy - Wikipedia<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSame-origin_policy&data=02%7C01%7C%7C201d982fc0d241d062ef08d65ba7590a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636797171638615991&sdata=NQyYumnXM%2BcQuEX10yebavKNVLAOfjNEd1EuZln14Os%3D&reserved=0>
In computing, the same-origin policy is an important concept in the web application security model.Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.An origin is defined as a combination of URI scheme, host name, and port number.
en.wikipedia.org

________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Booth Martin <booth@xxxxxxxxxxxx>
Sent: 05 December 2018 19:52
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Header set Access-Control-Allow-Origin for web services

I believe the following is an accurate report:

* The i is remote, reached by VPN. Lets call
"i.server.com:10000/web/services/Oceans" TheURL. This is a web
service providing a short list of 5 oceans from QMYLIB/OCEANSP.
* There is also an HTTP server set up on the TheURL's domain with a
website using JavaScript. That JavaScript presents a web page with
a nicely formatted layout and attempts to retrieve the Oceans data
from TheURL. It fails with the CORS failure.
* Eclipse is installed on my PC and the same JavaScript set-up is
installed there, pointing at TheURL. It fails with the CORS failure.

If I point my regular browser at TheURL i immediately get the 5 oceans
returned to me. Both JavaScript installations give me the CORS
failure. In other words, any regular web browser inside the VPN can
easily retrieve the data, but a JavaScript server at the same domain is
blocked???

Thats just ridiculous; therefore, I am misunderstanding something.

On 12/5/2018 12:15 PM, Justin Taylor wrote:

Sounds like cross-site scripting. By default, JavaScript (JS) is prevented from calling servers other than the origin server that served the initial page.

Is you JS trying to call a different server?

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7C201d982fc0d241d062ef08d65ba7590a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636797171638615991&sdata=dai3xYmJ8RLl5bSEUQoE5zgAOKAic2cvpG3cv%2Bds2kc%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7C201d982fc0d241d062ef08d65ba7590a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636797171638615991&sdata=R1%2Bb5XMaTZbcjkKYJaLfLtZ7G3NAw6O%2F0vXnlQjfmlg%3D&reserved=0.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7C201d982fc0d241d062ef08d65ba7590a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636797171638615991&sdata=dai3xYmJ8RLl5bSEUQoE5zgAOKAic2cvpG3cv%2Bds2kc%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7C201d982fc0d241d062ef08d65ba7590a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636797171638615991&sdata=R1%2Bb5XMaTZbcjkKYJaLfLtZ7G3NAw6O%2F0vXnlQjfmlg%3D&reserved=0.