CORS is part of the original web security model, but is not secure and should not be used for server security.
CORS = Cross origin resource sharing ... Cross-Origin Resource Sharing (CORS)
|
|
|
| | |
|
|
|
| |
Cross-Origin Resource Sharing (CORS)
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a...
|
|
|
It is easily spoofed with readily available browser add-ons, such as the HeaderHacker Chrome extension, which is quite useful for certain testing purposes.
All browsers and responding HTTP servers use CORS, but these days developers use CORS mostly to ensure they are getting to the right place.
HTTP servers by default are set to not allow resource sharing across domains. A domain change can happen if you are just using a different port for a resource.
So, even from the same IBM i, if you display a page from a cgi program from one port, then use a web service to get data via ajax on another, you'll get a CORS denial.
To avoid this, I always set CORS to allow cross origin requests, on all my HTTP server setups.
Also, you may still get an error depending on where you are requesting from. I also always set my servers to allow the content type directive.
If you are running APACHE 2.4,(V7r2 +) in the <Location/> section of your HTTP server configuration file after "Require all granted" add the following lines (you'll need to restart the server)..
Header Set Access-Control-Allow-Origin *
Header Set Access-Control-Allow-Headers "Content-Type"
If you are running prior APACHE releases (V7r1 -) in the <Location/> section of your HTTP server after "allow from all" add the following lines (you'll need to restart the server)..
Header Always Set Access-Control-Allow-Origin *Header Always Set Access-Control-Allow-Headers "Content-Type"
Even if you are using CGI, or PHP, or NODE for serving the response, you would need to add the corresponding CORS directives.
By the way, for most web services (sending more than few k), using an Apache HTTP server and a CGI program is WAY faster than the other solutions, especially web services. I have benchmarked this on small to large boxes. Its also much simpler to change a CGI program than a web service setup - especially if you want to change the parameters. Granted, if you need JSON on the receiving end, you'll have to encode it but there are available JSON encoders (YAJL is one). If you are sending a boatload of data, its better not to send JSON anyway, js style arrays or a delimited text field are better and javascript can parse arrays/strings faster as well (just have to escape any embedded double quotes).
On Wednesday, December 5, 2018, 3:53:12 PM GMT-3, Booth Martin <booth@xxxxxxxxxxxx> wrote:
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?
midrange.com
