Talk:Cross-origin resource sharing

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

JavaScript Low‑importance

	This article is within the scope of WikiProject JavaScript, a collaborative effort to improve the coverage of articles related to JavaScript, and to the development of user scripts for use on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.JavaScriptWikipedia:WikiProject JavaScriptTemplate:WikiProject JavaScriptJavaScript articles
Low	This article has been rated as Low-importance on the importance scale.

Is the W3C recommendation really deprecated?

The reality is that browser vendors use the spec in the fetch standard, not the antiquated W3C spec. So we can't mislead people by implying that the W3C spec is current.

However, is it actually deprecated? The only source for the claim in the introduction that the W3C recommendation is deprecated is a link to minutes from some W3C internal meeting. That does not show that they deprecated it; it only shows that some people resolved to do so at a meeting. In the end it may or may not have actually happened. And in fact, it didn't happen: the resolution at the meeting was to mark the recommendation as deprecated officially on the W3C site, and to add a note to that effect to the preamble of the spec. Years have passed, and that never happened. So we can't state that it is deprecated, at least not based on that reference.

Maybe it's just W3C bureaucratic/political inertia - I don't know.

I'll try my hand at re-wording to reflect reality. StormWillLaugh (talk) 13:37, 8 December 2019 (UTC)[reply]

Server Side Control vs. Browser Side Control

CORS should be a control at the browser side, but it went to the wrong way, it got to the server side. More specifically, when you are at http://www.1st.com/sthFrom1st.html, you want to access http://www.2nd.com/otherthing.html with javascript or java applet. Your browser will not allow this because of the "same origin policy". Now to extend this, it is also a policy for the browser, then why get into the server side to control the server? Got crazy? CORS is a control at the server side http://www.2nd.com which is different from www.1st.com.

The webpage sthFrom1st.html needs to tell the web browser what sites can be deemed as the same origin.

In fact, I think that this is easy to specify. In the html head, we can specify additional domains should be allowed to access. Browsers read these, then the original domain and the additional domains are all deemed to be the same origin. Currently, it is the browser block us. I am at http://1st.com/a.html, then I access http://2nd.com/d.html, with ajax or xmlhttprequest, use firefox, I can clearly see that the remote server returns everything, and everything is good. but the browser does not allow me to access the content.Jackzhp (talk) 23:58, 25 June 2011 (UTC)[reply]

This is not the right place for discussing the future of browser technology. I suggest you bring your use case and proposal to the mailing list of the Web Applications Working Group of W3C, where CORS, the specification of Cross Domain control in your terminology and the subject of this entry, is being developed. I'll delete your section for the moment as "we" (and also future stuff) is fairly rare in Wikipedia. — Kennyluck (talk) 22:29, 27 June 2011 (UTC)[reply]

For my own reference, at the client side, Content Security Policy should be utilized, CORS related stuff should be at the server side. And the current situation is explained in the BULLSHIT section below. Jackzhp (talk) 07:08, 21 October 2017 (UTC)[reply]

Requested move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: moved to Cross-origin resource sharing. Favonian (talk) 22:08, 16 February 2012 (UTC)[reply]

Cross-Origin Resource Sharing → Cross-origin resource sharing – Sentence case. http://wiki.riteme.site/wiki/Wikipedia:Manual_of_Style#Article_titles XP1 (talk) 13:27, 9 February 2012 (UTC)[reply]

Support. Clear WP:CAPS case. Jenks24 (talk) 05:41, 10 February 2012 (UTC)[reply]
Support per User:Jenks24. I came across a lot of stuff like that when I used to tidy Category:Acronyms. Callmederek (talk) 22:03, 16 February 2012 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

URLs in examples

The following URL, used in the "simple example" section, does not follow best standard practice. As per RFC 2606:

 http://www.example-social-network.com

should be:

 http://social-network-service.example.com

— Preceding unsigned comment added by 190.18.14.46 (talk) 16:08, 1 January 2013 (UTC)[reply]

Orphaned references in Cross-origin resource sharing

I check pages listed in Category:Pages with incorrect ref formatting to try to fix reference errors. One of the things I do is look for content for orphaned references in wikilinked articles. I have found content for some of Cross-origin resource sharing's orphans, the problem is that I found more than one version. I can't determine which (if any) is correct for this article, so I am asking for a sentient editor to look it over and copy the correct ref content into this article.

Reference named "ars-blink":

From Opera (web browser): "Google going its own way, forking WebKit rendering engine". Ars Technica. Retrieved 4 April 2013.
From Blink (layout engine): "Google going its own way, forking WebKit rendering engine". Ars Technica. April 2013. Retrieved 4 April 2013.

I apologize if any of the above are effectively identical; I am just a simple computer program, so I can't determine whether minor differences are significant or not. AnomieBOT ⚡ 03:51, 30 August 2015 (UTC)[reply]

Maintenance and rating of JavaScript articles

Concerning editing and maintaining JavaScript-related articles...

Collaboration...

If you are interested in collaborating on JavaScript articles or would like to see where you could help, stop by Wikipedia:WikiProject JavaScript and feel free to add your name to the participants list. Both editors and programmers are welcome.

Where to list JavaScript articles

We've found over 300 JavaScript-related articles so far. If you come across any others, please add them to that list.

User scripts

The WikiProject is also taking on the organization of the Wikipedia community's user script support pages. If you are interested in helping to organize information on the user scripts (or are curious about what we are up to), let us know!

If you have need for a user script that does not yet exist, or you have a cool idea for a user script or gadget, you can post it at Wikipedia:User scripts/Requests. And if you are a JavaScript programmer, that's a great place to find tasks if you are bored.

How to report JavaScript articles in need of attention

If you come across a JavaScript article desperately in need of editor attention, and it's beyond your ability to handle, you can add it to our list of JavaScript-related articles that need attention.

Rating JavaScript articles

At the top of the talk page of most every JavaScript-related article is a WikiProject JavaScript template where you can record the quality class and importance of the article. Doing so will help the community track the stage of completion and watch the highest priority articles more closely.

Thank you. The Transhumanist 01:07, 12 April 2017 (UTC)[reply]

BULLSHIT

Dude, all this paranoid security BULLSHIT is destroying the Internet! — Preceding unsigned comment added by 185.51.75.214 (talk) 16:43, 13 April 2017 (UTC)[reply]

I can see that you are frustrated as I did. Eventually I realized that the our frustration came from the fact that those smart people is not willing to clarify why CORS is indeed needed. I really want to chenge the first paragraph of the article, but there are many people like to remove what I edit, so I put it here: Jackzhp (talk) 07:06, 21 October 2017 (UTC)[reply]

CORS is a mechanism for a web server to delegate its Origin/Referrer based authorization check to web browsers. Why the Origin/Referrer based authorization check is needed? Since a web browser can open several web sites at the same time, for a site with confidential data, at least the confidential data should not be allowed to be accessed by any other web sites unless stated otherwise as did with Content Security Policy. In order for the web server to allow some specific other sites to access its resources, the web server should check the request's origin before serve the request. This is the Origin/Referrer based authorization check. However, at present, almost all web servers take the assumption as granted: other web sites will not access confidential data of my site which is guaranteed by the old same origin/site policy, they do not do the Origin based authorization check at all. That's to say the origin based authorization check is delegated to web browsers. And then when the confidential data of a web site grants access to some specific sites, it can achieve this only by notify the web browsers with CORS. That's to say to delegate even more origin based authorization check to web browsers. Jackzhp (talk) 07:06, 21 October 2017 (UTC)[reply]

What Problem does CORS solve?

The article suggests CORS lets you circumvent the same-origin security policy. But that explanation is nonsense. Disabling the policy altogether would do the same thing. One would expect that CORS somehow provides an alternative to the same-origin security policy. But how is it secure? How does CORS impede a malicious actor? — Preceding unsigned comment added by 76.17.159.243 (talk) 03:06, 22 June 2023 (UTC)[reply]

Is "same" in "wildcard same-origin policy is ... " correct?

Where the text says:

A wildcard same-origin policy is appropriate ...

and:

A wildcard same-origin policy is also widely and appropriately used ...

isn't the word "same" incorrect? Those case are talking about cases where the origin is not the same as the called server, right?

Dsb765 (talk) 00:43, 30 June 2020 (UTC)[reply]

The first sentence of the article was confusing and arguably misleading about what CORS are

The first sentence of the article was confusing and arguably misleading about what CORS are, which has disastrous consequences on web security considering how many web developers misunderstand the basics of it. The new one is more accurate, precise, and intelligible. For reference:

The old one: "CORS is a mechanism that allows restricted resources on a web page to be accessed from another domain outside the domain from which the first resource was served.
The new one: "CORS is a mechanism that allows a web page to access restricted resources from a server on a domain different than the domain that served the web page."

Viybel (talk) 20:06, 8 April 2024 (UTC)[reply]