User agents (e.g., Web browsers) have traditionally restricted scripts within web pages by a Same Origin Policy, which allowed scripts to make requests only to resources within the same domain from which the scripts themselves originated. This restriction is meant to protect the user and their computer from "Trojan horse websites" which may appear to be safe, but which then make unsafe HTTP requests to other, invisible sites. This restriction also protects the second website from potential "Denial of Service" and other attacks, whether accidental or intentional.
This policy has the unfortunate side-effect of also preventing client-side Web applications served from one website ("Origin") from retrieving data from another website ("Origin").
Cross-Origin Resource Sharing (CORS) is a mechanism intended to enable safer client-side cross-origin requests, primarily focused on data.
Authentication and session-management information methods are extended in several ways.
Access-Control-Allow-Origin
HTTP response header, with a value of the request's triggering script's site of origin (that is, the site which provided the script which made the request for the resource), to indicate whether access to the resource's contents may be allowed.
The user agent validates that the value in this header matches the actual origin of the script which made the request.
Origin
HTTP request header to discover whether the user agent deemed it a cross-origin request.
Here, the server-side application enforces limitations (e.g., returning nothing, partial results, or full results) on the cross-origin requests that they are willing to service at all.
With Virtuoso 6 and later (specific earliest versions as noted below), CORS support may be configured at the server-level or enabled through application logic (scripting, PL, etc.).
When working with older versions of Virtuoso, CORS support cannot be configured at the server-level, but it may be enabled within application logic (scripting, PL, etc.).
*
", or a space-delimited list of HTTP server URIs, e.g., "http://example.com:8080 http://blah.example.com http://foo.example.com
".
Scripts originating on the listed HTTP servers are authorized to retrieve the specified resource(s); the wildcard means scripts from any HTTP server will be authorized.
For this example, enter the following single URI:
http://demo.openlinksw.com
Any Virtuoso PL (VSP)-based application can implement CORS checking through well-known HTTP functions http_request_header()
and http_header()
.
This method will work with any version of Virtuoso.
For instance --
<?vsp IF (http_request_header (lines, 'Origin', NULL) = 'http://host.org') { http_header ('Access-Control-Allow-Origin: http://host.org\r\n'); } ELSE { RETURN; } -- Additional code here --- ?>
Applications running in other hosted environments (Perl, Python, PHP, ASP.NET, etc.) may also use their specific scripting options to add and/or check relevent headers.
http://demo.openlinksw.com/
is in the CORS list.
$ curl -i http://demo.openlinksw.com/mytest/test.vsp HTTP/1.1 200 OK Server: Virtuoso/06.02.3129 (Win32) i686-generic-win-32 VDB Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 Date: Thu, 28 Oct 2010 09:27:54 GMT Accept-Ranges: bytes Content-Length: 0
http://demo.openlinksw.com/
is in the CORS list.
-H "Origin: http://demo.openlinksw.com"
.
$ curl -i -H "Origin: http://demo.openlinksw.com" http://demo.openlinksw.com/mytest/test.vsp HTTP/1.1 200 OK Server: Virtuoso/06.02.3129 (Win32) i686-generic-win-32 VDB Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 Date: Thu, 28 Oct 2010 09:40:21 GMT Access-Control-Allow-Origin: http://demo.openlinksw.com Accept-Ranges: bytes Content-Length: 7
Access-Control-Allow-Origin
:
$ curl -i http://demo.openlinksw.com/mytest/test.vsp HTTP/1.1 200 OK Server: Virtuoso/06.02.3129 (Win32) i686-generic-win-32 VDB Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 Date: Thu, 28 Oct 2010 09:45:01 GMT Accept-Ranges: bytes Content-Length: 7