Remote Dynamic Web Page CORS error

[Jeff]

I need to host a Dynamic Web Page remotely from the BRX PLC.
Using browsers: Chrome, Firefox & Edge all have a similar error.  CORS header ?Access-Control-Allow-Origin? missing. Status code: 200
Using Chrome if I turn on the Moesif CORS extension then everything works great.  This Moesif work around has been great for development but now I need to fix the problem so others can access the Web Page.
This problem exists if I am using the Do-More simulator and browser on the same desktop computer or using my Apache Web Server to host the web page and pull the data from a BRX hundreds of miles away.
BRX System Configuration, White pages:  Ethernet/IP - "Service Open"  and  HTTP and REST API - "Service open"


Question:  Is there a location in the BRX System Configuration that I can allow my web page access to the BRX data without creating this cross domain error?

Thank you in advance; Your BRX line of PLCs with Do-More are incredible!

Jeff

 

[Greg]

...BRX System Configuration, White pages:  Ethernet/IP - "Service Open" and HTTP and REST API - "Service open"

Question: Is there a location in the BRX System Configuration that I can allow my web page access to the BRX data without creating this cross-domain error?...

By "Service open", does this mean that you have not put an "X" in the Service in the Server Whitelist Settings, and then used the <Add...> button to add the IP addresses of the clients (browser locations)? Also, have you tried specifically whitelisting those clients' IPs? Just curious.

Someone else here at Host Engineering may be more qualified to help you with this, but your explanation made me want to ask those questions. ?\_(ツ)_/?

[Jeff]

Greg,
Great Question!  I went back and read the instructions for White pages.  I have not added any IP address and they are required (my oversight).
Using the Do-more simulator and loading a dynamic web page into Chrome I still get the CORS error in the browser after entering every possible range of IP address that seemed reasonable into the White Pages.  I suspect the problem lies with what IP address the Do-more simulator is actually seeing arrive from my Chrome browser.  I will pursue this but if anyone has any insights they are always greatly appreciated.
Thankyou Greg for getting me off dead center!
Jeff

[Jeff]

I have not been successful.  My problem is the same as "Bolts" dated June 13, 2023 - no solution posted.

Simplest configuration to duplicate problem:

A. Simulator copies 125 too D1.
B. Chrome Web Browser executes simple web page  using json &  "Get" command to obtain D1.
C. Response from Web Page: CORS Error Missing Allow Origin.
D. If I add the Moesif Cors Ext app to chrome the web page will then load the value of D1 (Not a permanent solution).


Question: Is there a configuration or device that will allow a Web Page to pull data from the BRX?
Thank you in advance.

[Greg]

Question: Is there a configuration or device that will allow a Web Page to pull data from the BRX?
Thank you in advance.

The BRX web server does not send CORS headers, so your browser, and your HTTP GET request are the ones requiring that. That's why your Chrome browser extension (which bypasses the need for CORS) allows it to work. As far as I know (which isn't much), can you not access the BRX's API utilizing a URL of the proper format programmatically? (i.e. http://<BRX-IP-Addr>/data/json?MyD1=D1).

Does that work?

[Bolt]

I did get my system working, accessing the data from a externally hosted device and displaying it within a webpage. I'm not sure what the real issue was that my dev was running into to cause the CORS error. It was frustrating, as the data displayed fine in a web browser URL API request. Sorry I'm not much help here.

[Greg]

...It was frustrating, as the data displayed fine in a web browser URL API request. Sorry I'm not much help here.

Well, that's what I was thinking.

I'm going to also say that I bet it would work if a proxy server was setup as well. It could act as a go-between. And since it is not a "browser" or using a HTTP GET, then CORS wouldn't come into play. It could simply forward the request from his client to the BRX web server. The thing is, our web server is answering every time. It doesn't "care" whether or not it has CORS. It is the "browser" that cares.

Again, I'm no expert on this, but that's what I think I know at the moment, until someone who knows better can tell me.

[Jeff]

Greg,

Thank you for your responses.

A. "BRX server does not send CORS headers":  This helps I thought maybe I was missing something on BRX configuration.

B. If I type this URL into three different web browsers:  http://BRX-IP-Address/data/json?DValue=D1   I get the response: DValue: 123       (D1=123 in simulator)
 
C. My Web Page has the following:
 <script>
var xmlhttp = new XMLHttpRequest();
xmlhttp.overrideMimeType("application/json");
xmlhttp.onreadystatechange = function()
{
  if (this.readyState == 4 && this.status == 200)
  {var myArr = JSON.parse(this.responseText);}
{
         document.getElementById("MResHatch").innerHTML =  " Main Res. Hatch:" + myArr.DValue;
}
};
function updatedata(){
     xmlhttp.open("GET", "http:// BRX-IP-Address /data/json?DValue=D1",true);
 xmlhttp.send();
    setTimeout(updatedata, 1000);}
updatedata(); 
</script>

This triggers a CORS error on all three browsers.

 D. I agree that a proxy server could be a work around.
E. I will E-mail you a two page document that I find well written on the CORS security protocol.  My reading of it makes the BRX the server that controls access by only providing a correct CORS response to approved Web Pages.

Thank you for your support, hopefully ?Bolt? is like me and will wake up at 2AM remembering how he solved this problem.
Jeff

[Bolt]

...hopefully ?Bolt? is like me and will wake up at 2AM remembering how he solved this problem.

Why would you wish that upon me, it happens enough already!

Digging through old notes, this link seemed to help me. I can't quite tell though if that was the final solution though. Not sure what kind of device you are running your server on, I was using an SBC.

https://ubiq.co/tech-blog/set-access-control-allow-origin-cors-headers-apache/

I'd like to take this moment and suggest that Host cram a full blown web server onto a BRX, where we can run a virtual HMI right on the unit with 2 way read/write available. Or maybe node-red. Should be easy, right?

[BobO]

I'd like to take this moment and suggest that Host cram a full blown web server onto a BRX, where we can run a virtual HMI right on the unit with 2 way read/write available. Or maybe node-red. Should be easy, right?

Easy? With the hardware we have? No. With future hardware we're planning to build, it might not be too bad.

I'm not OK with allowing writing to the PLC until the web server is secure and I'd prefer to have the PLC and server functions operating from entirely different processors and memories. Fortunately we know how to do this. 

I gotta say, it is really fun to be talking about doing stuff like that again. The last several years have been really hard and all of the good ideas had to be put in stasis. We're finally starting to work on things we were planning when the pandemic/supply chain crisis hit.

[Greg]

...E. I will E-mail you a two page document that I find well written on the CORS security protocol.  My reading of it makes the BRX the server that controls access by only providing a correct CORS response to approved Web Pages...

The document makes it sound that way, but it is not entirely accurate. The BRX web server simply responds to the HTTP request without considering CORS headers because it doesn't inherently enforce CORS restrictions. It's the client (e.g. a browser) that enforces CORS based on the response headers it receives. If the client making the request does not require CORS, or if CORS restrictions are bypassed (e.g. a proxy server), then the data from the BRX web server will indeed show up at your client. In other words, we are sending the data you requested. But when the data arrives at the client, it is the client that rejects it and gives you the CORS error.

Now, that being said, what we will do in the next release of the BRX firmware, is allow you to make a user header. We already allow this from the BRX's point of view if it is the client requesting data using the HTTPCMD instruction. In that instruction, you can check the "Additional User Request Header" and add whatever header you want. So, we will do the same for when you enable the BRX web server's REST API. We'll put some dialog in there that will allow you to create your own header. This will allow you to create your own CORS header that you would like us to respond with. Then when your client requests data (like you are currently doing), this user-defined header will be included. Then when your client sees the properly formed CORS header that you created, you will no longer get the error.

But understand, the proper formation of this user header (in your case, a CORS header) will be totally up to you. By default, this feature will not be enabled.

How's that sound? 

[BobO]

Done.

[Bolt]

Easy? With the hardware we have? No. With future hardware we're planning to build, it might not be too bad.

I'm not OK with allowing writing to the PLC until the web server is secure and I'd prefer to have the PLC and server functions operating from entirely different processors and memories. Fortunately we know how to do this. 

I gotta say, it is really fun to be talking about doing stuff like that again. The last several years have been really hard and all of the good ideas had to be put in stasis. We're finally starting to work on things we were planning when the pandemic/supply chain crisis hit.

My sarcasm is typically lost via the keyboard.

I don't disagree with your stance. An add on processor would be ideal. But security is relative, sandboxed memory such as modbus registers is equally insecure.

The more integrated things become, the more I run into applications were we just need a simple UI accessible from a local network or similar. It's not always feasible to put in an HMI for a few things, nor would that HMI be accessible or looked at by the user. And rolling my own interface on a Raspberry Pi or similar is not exactly fun either. I just see platforms such as WebVisu and wish we had a similar option in the pipeline.

[BobO]

My sarcasm is typically lost via the keyboard.

I don't disagree with your stance. An add on processor would be ideal. But security is relative, sandboxed memory such as modbus registers is equally insecure.

The more integrated things become, the more I run into applications were we just need a simple UI accessible from a local network or similar. It's not always feasible to put in an HMI for a few things, nor would that HMI be accessible or looked at by the user. And rolling my own interface on a Raspberry Pi or similar is not exactly fun either. I just see platforms such as WebVisu and wish we had a similar option in the pipeline.

Nah, I knew, I just wanted to address it for those who might not. Folks these days get so used to the miraculous that they've lost appreciation for what is miraculous.

The original intention for user pages in BRX was to add an instruction that would allow generation of text pages (similar to the top info page) and automatically link them into the site. We really couldn't come to agreement as to what would be good enough for the typical user, so we kicked it down the road. I am still of the belief that a table based instruction that generated what amounts to fancy data views on a web page would be good enough for many, but the counter point was that it really needed Javascript graphical controls and such. Until the web server is HTTPS I wouldn't consider writing, so it really can't do anything but monitor so I don't know how useful that is either way.

The next generation controller will be designed to address both the need to deterministically and reliably solve logic, and the need to communicate in environments that present challenges to the same. Think "logical air gap".

[Jeff]

Greg,

Adding "Additional User Request Header".

That would be fantastic!  Or is it now Awesome!  (I struggle with keeping current).
Just shooting from the hip about how many months will that be.
I am a compulsive planner!

Thanks,
Jeff