Cross origin issues

[jcayouette]

Cors party time ;)

A friend and I have setup a react app running on localhost:3000.

We are sending an API command to the alpaca telescope simulator to slew to specific RA/DEC coordinates. ASCOM Remote is running on the same machine: 127.0.0.1:11111

We are able to successfuly send the requests with basic http requests / curl / postman and the command also works fine when disabling cors in Chrome --disable-web-security and --user-data-dir.

However if things are left to the defaults a cross origin error is thrown in the browser:

In ASCOM remote I see:

ERROR - ClientId: 0, ClientTransactionID: 0 - An unsupported HTTP method was used: OPTIONS

We are running the react app on: localhost:3000 We are running ASCOM Remote on: 127.0.0.1:11111

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Are there plans to implement OPTIONS in ASCOM Remote? How can we circumvent this issue without disabling security? Checking the "Enable Cors" box in ASCOM Remote does not work :(

One of the issues that I see is that the modern PUT is used over POST. This forces OPTION to be preflighted. Which is denied as ASCOM Remote does not support it. (If I understand correctly?).

in particular, HTTP methods other than GET, or POST with certain MIME types), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with the HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request." ~MDN

Looking forward to your response!

Happy to help, I love what Alpaca can become. :)

[Peter-Simpson]

Hi Joseph,

Thanks for reporting the issue. It seems that the browser is using the “pre-flight” CORS mechanic rather than the “simple request” mechanic that I implemented in the Remote Server. The Remote Server is rejecting the OPTIONS verb because it isn’t used in the Alpaca protocol or the simple request CORS protocol and there is consequently no implementation support.

If you can configure the browser to use the simple CORS request mechanic, I believe that will work.

I’ll have a look to see what is required to implement the pre-flight mechanic and will do so if it’s not too complicated. 😁

Best wishes, Peter

[jcayouette]

Thanks Peter 👍

OPTIONS requests are what we call pre-flight requests in Cross-origin resource sharing (CORS).

They are necessary when you're making requests across different origins in specific situations.

This pre-flight request is made by some browsers as a safety measure to ensure that the request being done is trusted by the server. Meaning the server understands that the method, origin and headers being sent on the request are safe to act upon.

Your server should not ignore but handle these requests whenever you're attempting to do cross origin requests.

A good resource can be found here http://enable-cors.org/

A way to handle these is to ensure that for any path with OPTIONS method the server sends a response with this header

Access-Control-Allow-Origin: *

This will tell the browser that the server is willing to answer requests from any origin.

For more information on how to add CORS support to your server see the following flowchart

http://www.html5rocks.com/static/images/cors_server_flowchart.png

Looks like we just need a check to see if the preflight OPTIONS is called and if so provide the response above.

Hope this helps!

UPDATE: Expecting users to modify their browser to support the simple request from my eyes is not best practice. I would handle the additional logic for the OPTIONS request/response rather than ignore this issue so it is transparent for them.

[Peter-Simpson]

Hi Joseph,

It seems that I did a better job than I remembered when I implemented CORS in ASCOM Remote. It does support the OPTIONS method.

I'm unable to reproduce the issue that you are seeing because Chrome works fine "out of the box" without me having to disable CORS.

To help me diagnose further, please can you:

• Ensure that CORS support is enabled in ASCOM Remote, it's the last tab on the setup dialogue.
• Enable debug logging
• Shut down the Remote Server and restart it so we get a new log file
• Send a command from your REACT app to illustrate the failure
• Close the Remote Server
• Zip and post the most recent ASCOM.Remote.Server...txt file in the most recent Documents\ASCOM\Logs 2023-04-XX folder

Hopefully this will throw some more light on what is going on.

Best wishes, Peter

[Peter-Simpson]

Hi,

I've found the root cause and will post a revised ASCOM Remote version later, no need to run the test above.

Best wishes, Peter

[Peter-Simpson]

Hi Joseph,

Please can you try this updated version. I have tested it as far as I can without having a JavaScript app and it seems to respond in line with the diagram in the link.

ASCOMRemote(6.6.8508.27743)setup.exe

Best wishes, Peter

[Peter-Simpson]

Hi,

Please can you let me know whether the new version fixes your issue?

Thanks, Peter

[jcayouette]

Sure, sorry for the late response! I am currently involved in a house renovation project. :). I will try and tackle the test this week and get back to you!

[Peter-Simpson]

Thanks Joseph, that will be much appreciated. I hope the house renovations go well!

[Peter-Simpson]

Hi Joseph,

Hopefully your house renovations went well and are now complete. Have you been able to test the fix?

Best wishes, Peter

[jcayouette]

Ugh, no, not yet. We had some major setbacks. Apologies for the late response @Peter-Simpson I will try to tackle it this in the next week if I can find some escape time!

[Peter-Simpson]

Thanks Joseph, I'll leave the issue open for a while longer.

Best wishes, Peter

[jcayouette]

I will close the PR, it looks like you fixed the preflight options in the latest release. I will test as I have time but due to our renovations around the house my time is currently stretched. "who's isnt?" :)

Update: I took a look at the commit history and the solution looks good. Thank you!

[Peter-Simpson]

Thanks for testing and letting me know Joseph.

Best wishes, Peter