Cross-origin errors due to http/https of c9


#1

I am developing an app that gives the user the ability to make a drawing using HTML5 canvas. When the drawing gets loaded on subsequent pages after the drawing is created, parts of the drawing don’t show up. Chrom dev tools show that the failure is due to Cross-Origin Resource Sharing (CORS). It seems cloud9 goes back and forth between http and https, so the browser thinks the app is trying to access another origin.

Is there anything I can do about this. Now and then I hard-code the URLs, but that got old real fast. :frowning:

Thank you in advance for some help with this.
Lori


Chrome throwing cross-origin error on apache test server, but works fine in Firefox
#2

Hey @loridp :slightly_smiling:,

Yeah this can be annoying. The best I’ve done for this so far is what you ended with, hardcoding the URLs but lately I’ve been using C9 mainly atop SSH servers and you wouldn’t have the problem with that setup.

Best,
Mikeumus


#3

Cloud9 shouldn’t switch between https and http unless specified (defaulting to http if the protocol isn’t included in the url). You can use // at the beginning of each asset url instead of http:// or https:// and the browser will load using whatever protocol the current page is using. Take a look at http://stackoverflow.com/questions/9646407/two-forward-slashes-in-a-url-src-href-attribute for more information.


#4

Excellent! Thank you @timjrobinson. I really appreciate it.


#5

“Atop SSH servers”. I don’t really understand what that means, but it sounds good, @mikeumus! Thank you for taking the time to answer my question. I really appreciate it. I’ll look at that “Atop SSH servers” thing. :slightly_smiling:


#6

Hi,

Another thing I’ve noticed in these kinds of issues is that the application url isn’t public. Thus, when an external API tries to access the application, it doesn’t have authentication and is directed to the Cloud9 auth page. Can you check if the application url is public? If, make it public by going to the IDE, click on Share, and check Public on the ‘Application’ row.

I hope this helps.

Regards,
​Mutahhir


#7

Hi @mutahhir! Thank you for this information. I think this just might be the ticket. I hadn’t thought of this before. I tend to use relative urls within the pages of my apps, so I’m not directly specifying “http”. So I think this is probably the best solution to my problem. Before I implemented your suggestion, I couldn’t even get Internet Explorer to access the site from my c9 workspace.

So thank you so mych! I really appreciate it.


#8

This failed for me after I changed my workspace from public to private…

Calling the now private url would produce the following response

Status Code:302 Moved Temporarily

as the response from the server was now asking for authentication

https://c9users.io/_user_content/authorize?redirect=httpsxxx.c9users.io

This was causing an error that looked as though it was a CORS problem.

Fetch API cannot load https://xxx.c9users.io. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘https://xxx.c9users.io’ is therefore not allowed access. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

Sharing the application from my now private workspace removed the authentication response and fixed the issue.