CORS error on same domain?

Question

I'm running into a weird CORS issue right now.

Here's the error message:

XMLHttpRequest cannot load http://localhost:8666/routeREST/select?q=[...] 
Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin

Two servers:

• localhost:8666/routeREST/ : this is a simple Python Bottle server.
• localhost:8080/ : Python simpleHTTPserver where I run y Javascript application. This app is executing Ajax requests on the server above.

Any thought on what could be the problem?

EDIT:

And... the port was the problem. Thanks for your answers :)

If anyone is using a Python bottle server as well, you can follow the answer given on this post to solve the CORS issue: Bottle Py: Enabling CORS for jQuery AJAX requests

Moisten

Since they are on different ports there are not the same! – Talebearer

The port numbers are different. This might violate Cross Origin rules. – Backbreaking

Note that IE doesn't take port number into account. – Frankiefrankincense

@Talebearer Most browsers also conclude they're not the same if one has a 'www' and the other doesn't. The devil's in the details. – Kayak

@SeldomNeedy example.com, www.example.com, www1.example.com, and mirror.www.example.com are all different domains. example.com, example.com, example.com, example.com:80443 are all from different origins. – Talebearer

Some webbrowser allow it and others don't . Webbrowser seem to be stuck in the era of monoliths, while all back-ends are migrating to multi-server environments. All selfrespecting websites disable CORS to some degree. How else can you support http+https+websockets+www+loadbalancing+api-servers+... Some security settings are so extreme that everybody disables them and totally miss their point. – Exterminate

@RayNicholus no, you are wrong. – Chloe

@Chloe RayNicholus was probably right in 2013 when the comment was made. – Talebearer

Answer 1

It is only the same if the scheme, domain and port are identical. Same Origin Policy

Clarification

• http and https are not the same scheme. (By default they also use different ports)
• example.com and www.example.com are not the same domain.
• Port 80 and 443 are not the same port.

How to enable CORS

If you want to enable CORS you must follow Cross-Origin Resource Sharing (cors) by adding headers. Mozilla has examples

You need to add Access-Control-Allow-Origin as a header in your response. To allow everyone (you should probably NOT do that):

Access-Control-Allow-Origin: *

Multiple orgins

If you need to support multiple origins (for example both example.com and www.example.com), set the Access-Control-Allow-Origin in your reply to the value of the Origin-header from the request (after you verified that the Origin is white-listed.)

Also note that some requests send a preflight-request, with an OPTION-method, so if you write your own code you must handle those requests too. See Mozilla for examples.

Talebearer

This should be highlighted with red colour, capitals and bold everywhere where AJAX gets involved. – Cutin

As an addendum to this answer, note that 'Access-Control-Allow-Origin: https://example.com' is NOT equivalent to 'Access-Control-Allow-Origin: https://www.example.com'. If your site is accessible via both of those, you should have both in your response-headers. – Kayak

Note that no preflight requests are sent by default for simple requests like GET, POST and HEAD. See the MDN article linked in the answer for additional details. – Aspirator

@SeldomNeedy you cant have duplicate headers – Prettify

@MikeFlynn My wording was admittedly a touch loose, but I wasn't trying to suggest that; the server simply needs to be configured to send the appropriate header, per the request. – Kayak

Answer 2

The port numbers are different.

A request is considered cross-domain if any of the scheme, hostname, or port do not match.

Seamount

Except 443 and 80. – Deliquescence

including 443 and 80 – Aq

How can a confirmation to the problem can be the solution of the problem ? Post the answer dude. – Quietly

Answer 3

Even Including http:// Or https:// At The Front Matters

I know the title may be stating the obvious for many, so PLEASE allow me to explain. When testing an operation to call an API developed with Python FastAPI, you define the URLs allowed to access the API directly in the API code. I'll leave an example at the end.

I found that I could get away with NOT using http:// at the front when testing from JavaScript running on my localhost, BUT when I ran the same API from a Docker container, I kept getting CORS violations. I hadn't remembered this being a problem with past usages of this API.

WHEN I ADDED http:// to the front of my allowed server names and ports, BOOM - access allowed.

I hope this saves someone the time that I lost ;-) !

Example Fast API CORS Settings:

# Container
long_server_name = "http://SomeFullyQualifiedServerName"
short_server_name = "http://SomeServerName"

# Local
# server_name = "http://127.0.0.1"

origins = [
    "http://127.0.0.1:8000",  # Conductor API
    "http://127.0.0.1:5500",  # Conductor Runner Dev
    "http://127.0.0.1:5501",  # Quote Runner Dev
    "http://127.0.0.1:5502",  # Quote Runner Dev
    f"{long_server_name}:5000",  # Conductor Web UI
    f"{long_server_name}:5001",  # Quote Runner
    f"{short_server_name}:5000",  # Conductor Web UI
    f"{short_server_name}:5001",  # Quote Runner
]

app.add_middleware(
    CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

Peria

http and https are different schemes, and they also use different ports by default. By not specifying the scheme, the browser will interpret it as a relative url and use the same scheme that the page was loaded with. So, yes, it matters. – Talebearer