In this video we'll talk about the limitations of cross-site HTTP request as well as the need
for cross-site origin resource sharing and how to set this up in the PI Web API.
First what are cross-site HTTP requests?
When a client makes a request to the PI Web API service and a client and the PI Web API are on
different domains this is considered a cross origin request. These requests are blocked
by default. This is where cross-origin resource sharing comes into play or CORS. The PI Web API
server has a set of configurational parameters which specifies the urls, methods and headers
that are allowed to be requested from slash by a cross-origin resource. Within CORS there are
two types of requests: simple requests which use get, head or post and no custom headers. All other
requests are considered complex requests. While simple requests are what we would expect when
you submit a request it's directly to the server, complex requests require you to make two requests:
a pre-flight request and the actual request. The pre-flight request is
one that asked the server if the methods, headers and URL are supported or allowed.
Let's illustrate this with an example. I have a simple web page with some JavaScript which queries
the PI Web API for the list of AF databases via an ajax call made by jquery. When a user clicks on
this button from the HTML page it will query the PI Web API for the AF databases. As you can see
when we click on this button the databases are not returned. When we open up Chrome developer
tools we can see all of the requests going on behind the scenes. In the console we can see that
we're getting an error: a no access control allow origin header. This is because I'm hosting the web
page locally but the PI Web API is on the domain. So the request is blocked for security reasons.
Under the network tab, if we make the request again,
we can see each of the individual pieces of the request here. We can see that it's a get
request and that our origin is localhost. To fix this issue we're going to go into the PI
Web API configuration database and take a look at the attributes. We can see that there are a
number of attributes that are related to CORS. These are the parameters that the PI Web API
service checks against to see if our request is from a different domain is allowed. We need
to make a few changes to allow our JavaScript application to get information from the PI Web
API service. We'll need to ensure the origin is listed here as part of the CORS origins.
Since we're making a get request the method we know is already allowed. Let's check this in
and go back to our web page. The PI Web API checks the AF configuration once every 15
seconds or so. Thus if we wait about 15 seconds after checking in the changes we should be able
to try this request again and have it succeed. This time we see that the access control allowed
credentials header and the response must be set to true. Let's go back to our CORS attributes. As
we can see here the CORS supports credentials is set to false. Let's change this to true. Check in
that change and try this once again. And now we can see our two AF database is being populated.
In this video we talked about cross-site HTTP requests as well as the need for cross-site
origin resource sharing and how to set this up in the PI Web API. We demonstrated that
when a client makes a request to the PI Web API service from a different domain
that this would be considered a cross-origin request and is subjected to CORS validation
parameters. We demonstrated that these requests are blocked by default and that the PI Web API
service has a set of configurational parameters which specify which urls,
methods and headers are allowed to be requested by the cross-origin resource.