No 'Access-Control-Allow-Origin' header is present on the requested resource.
-
@Jarry said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
well, their API doesn't includes test results:
so, there's that bit of unhelpful information
EDIT:
you can get the build log and parse it yourself
the build log does not include build ARTIFACTS
though i will eventually be pulling the build log associated with the build-log i construct, so there is that. :-D
-
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
I would argue that if they don't set the CORS headers they are, by definition, not public APIs.
Yeah, after @accalia posted her workaround I realized she's requesting a build artifact file, not a REST endpoint... that's just a normal resource request and not really an API request; requesting a resource from another server is what XSS protection is intended to prevent.
It'd still be cool if Appveyor had, say, a configuration option for your account that stated trusted domains that would be included in a CORS header (and they might be open to a request for such on their forums), but in the meantime I'd say everything's working as designed.
-
@heterodox said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
It'd still be cool if Appveyor had, say, a configuration option for your account that stated trusted domains that would be included in a CORS header (and they might be open to a request for such on their forums), but in the meantime I'd say everything's working as designed.
I'm sticking with my original advice: contact them somehow and ask "what's the dealio?"
The lengths some software engineers will go to to avoid talking to another human being is crazy to me.
-
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
contact them somehow and ask "what's the dealio?"
I just so rarely get useful answers when I do that even with paid support contracts that I rarely bother with free services.
-
Yeah me too. That doesn't mean it's not the first and most correct step to follow.
-
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
contact them somehow and ask "what's the dealio?"
Return-Path: <accalia.de.elementia@gmail.com> Received: from ?IPv6:::ffff:[MA_LOCAL_IP]? ([MAH_PUBIC_IP]) by smtp.gmail.com with ESMTPSA id g46sm85076qtb.33.2017.06.21.18.59.51 for <team@appveyor.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 18:59:51 -0700 (PDT) Message-ID: <594b2497.3131c80a.9b8ea.07d0@mx.google.com> MIME-Version: 1.0 To: "team@appveyor.com" <team@appveyor.com> From: Accalia de Elementia <accalia.de.elementia@gmail.com> Subject: Cannot retrieve build artifact via Javascript Due to CORS error. Date: Wed, 21 Jun 2017 21:59:48 -0400 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_45F69688-A22A-4433-B212-2CE548F644C2_" --_45F69688-A22A-4433-B212-2CE548F644C2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Good day, I am working on a project that wants to retrieve a JSON formatted build art= ifact from the latest appveyor build via a client side XHR request in order= to populate some client side graphs with data from the build artifacts. Unfortunately I am being blocked due to CORS errors when I make the XHR req= uest. After much hair pulling, googling, and more than a little swearing I= =E2=80=99ve been unable to get this feature to work. Is it possible to retrieve build artifacts from appveyor automatically in = a browser session? I have prepared a simple jsfiddle that demonstrates the error on Google Chr= ome 58.0.3029.110: https://jsfiddle.net/urL68qpd/ Appveyor progect in question: https://ci.appveyor.com/project/AccaliaDeElem= entia/compressiontest Github repository: https://github.com/AccaliaDeElementia/CompressionTest Thanks for your help, - Accalia
-
@accalia Well your language is still wrong, because you still don't understand that nothing here is an error, this is how CORS is designed to operated. Google just did a really shitty job of writing that error message, not surprisingly. Also thanks for copying all the bullshit email headers instead of just the stuff that matters, so everybody here has to scan past tons of gibberish to get to the actual content of the message, that's a lovely open source-y sentiment: make everything as ugly and difficult to use as possible.
But there you go.
-
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
Well your language is still wrong
My request caused an error to appear in my console where i wanted publicly available data. That means it's an error. Sure, the error is required by the design specification of CORS, but that does not mean it is not an error and so describing it as a CORS error is correct.
an error by design is still an error.
In fact i seem to recall you saying exactly that, or something to that effect anyway, some time ago when you were trying to do something with webapi2 and were having difficulty to it
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
Also thanks for copying all the bullshit email headers
I didn't want you to miss any important clue contained in my email to their support email.
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
publicly available data
No.
This is the fundamental misconception you're holding onto right now. Since your script is running in the browser, by design, any request it makes will inherit your authentication and status status. That means nothing crossing origins can be treated as publicly available unless it's explicitly marked as such. The alternative is WILDLY dangerous, if convenient for you.
-
@heterodox said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
publicly available data
No.
This is the fundamental misconception you're holding onto right now. Since your script is running in the browser, by design, any request it makes will inherit your authentication and status status. That means nothing crossing origins can be treated as publicly available unless it's explicitly marked as such. The alternative is WILDLY dangerous, if convenient for you.
Incorrect.
The data is publicly available. I require no authentification to access it.
if i required authentication i would not be able to access the url with the browser directly.
that means the data is public.
the same is true of the malware script that CORS is designed to stop from loading into your site.
the fact that CORS is a security mechanism does NOT mean that the data is not public, nor does it mean that the error i am encountering trying to load the data is not in fact an error.
the data is public, and the CORS security is causing the request to fail with an error.
these are the facts of the matter. Their interpretation is available for debate.
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
the same is true of the malware script that CORS is designed to stop from loading into your site.
That's not what it's there for.
the data is public, and the CORS security is causing the request to fail with an error.
I'm saying it CAN'T BE TREATED AS PUB-- sigh. Okey doke, whatever.
-
@heterodox said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
the data is public, and the CORS security is causing the request to fail with an error.
I'm saying it CAN'T BE TREATED AS PUB-- sigh. Okey doke, whatever.
is
https://google.com
public?- Yes.
can i load
https:/./google.com
via XHR?- No.
or do you argue with that?
-
@accalia I want to add that I think CORS is a very stupid security mechanism.
The browser should just not send any cookie or authentication token cross domains. Make it behave exactly as if you called curl from your server, because in the end, an attacker could do just that anyway.
-
@wharrgarbl said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@accalia I want to add that I think CORS is a very stupid security mechanism.
The browser should just not send any cookie or authentication token cross domains. Make it behave exactly as if you called curl from your server, because in the end, an attacker could do just that anyway.
or at the very least allow me to tell the browser "hey. i know CORS isn't enabled on the site. don't send any cookies or shit"
i mean i'm just a stupid fox but i think that would solve the CORS browser hijacking issue too
-
@accalia do you want every website to be able to send unauthenticated POST requests to any other website from your browser? Because that's how you get router exploits.
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
or at the very least allow me to tell the browser "hey. i know CORS isn't enabled on the site. don't send any cookies or shit"
Wow that sounds like a terrible idea. Any browser from anywhere could just PUT or POST to any site anywhere? By just saying "oh I'm not evil, please trust me"?
Set the "oh I'm not evil, please trust me" bit and all bets are off! Why even have security!
I'd actually argue the <script> tag rules should be brought in-line with the AJAX rules. The only reason those load from weird domains now is for backwards-compatibility. Then CORS (or an improved version of same) would be the end-all, be-all.
-
@ben_lubar said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@accalia do you want every website to be able to send unauthenticated POST requests to any other website from your browser? Because that's how you get router exploits.
fine, if you are concerned about POST and PUT than restrict them.
But let me GET data that you have put on the web without authentication in front of it.
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
Any browser from anywhere could just PUT or POST to any site anywhere? By just saying "oh I'm not evil, please trust me"?
yep.
but then so can literally any application with a network stack.
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
Why even have security!
why are we trusting the browser for security? if the browser is not allowed to send ANY cookies nor custom headers when making a non CORS request then the request is literally no different than a request from cURL or something i can construct from System.Web.WebClient. so the burden of additional security is on the web server servicing the reqauest no? just like it always was really.
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
i'm not mad at you. I'm mad at CORS. and when i get mad i get EVEN
When you get mad, it seems you actually get rather ODD
-
@TheCPUWizard said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
i'm not mad at you. I'm mad at CORS. and when i get mad i get EVEN
When you get mad, it seems you actually get rather ODD
ODD is my base state. i can't very turn ODD when i'm mad if i started there.
in fact it's rather odd for me to be EVEN
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
why are we trusting the browser for security?
Because we remember the world when browsers had no security.
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
if the browser is not allowed to send ANY cookies nor custom headers when making a non CORS request then the request is literally no different than a request from cURL or something i can construct from System.Web.WebClient. so the burden of additional security is on the web server servicing the reqauest no?
I dunno; I'd have to think about that. Smarter people than me have determined the current system is desirable. Maybe you're right; the only thing I can think of at the moment is DoS attacks, but those kind of work on CORS-enabled servers anyway because the server has to read enough of the request header to realize CORS should reject the request. If there's other types of attack your proposed feature allows, none are coming to mind right now.
So propose it to the W3C and then maybe in 47 years someone will think about maybe starting to possibly implement something.
-
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
why are we trusting the browser for security?
Because we remember the world when browsers had no security.
We trust the browser with security, a piece of software running on an unknown system by an unknown user that may or may not be doing what it says it is doing because we remember when they didn't have security?
yeaaaaah.
that makes sense.
I'mma going to code my server to trust the browser exactly as far as it can throw it.
@appveyor_team said:
Hi Accalia,
Seems like we have to enable CORS for Azure blob storage we use for artifacts https://docs.microsoft.com/en-us/rest/api/storageservices/cross-origin-resource-sharing--cors--support-for-the-azure-storage-services.
Give us please a few days to evaluate this from security standpoint, and we will update you.
Sorry for the trouble and thank you for reporting this.
‐ Appveyor Team
-
This thread is a great example of why our field needs to start teaching history. You don't just need to know how to do things, but you need to know why we currently do things the way we do.
-
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
This thread is a great example of why our field needs to start teaching history. You don't just need to know how to do things, but you need to know why we currently do things the way we do.
Teaching basic reading comprehesion and communication is jsut as important, if not more so.
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
jsut
Yes
I'm sure that's some kind of snipe at me. Listen, at the time CORS was implemented, I could probably have given you a dozen scenarios explaining why the scheme you propose can lead to security problems. I'm not Mr. Memory. Sorry.
Insert that terribly-written but insightful quote about how you don't tear down a fence until you know exactly why it was built in the first place. You're tearing down fences here. Maybe you're right and the fence isn't needed, maybe not-- the thing that concerns me is right now you don't know.
In any case, it doesn't matter because it takes the W3C 47 years (as stated above) to make any kind of decision and when they finally do they'll have misspelled referrer. So for now you just have to cope.
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
why are we trusting the browser for security? if the browser is not allowed to send ANY cookies nor custom headers when making a non CORS request then the request is literally no different than a request from cURL or something i can construct from System.Web.WebClient. so the burden of additional security is on the web server servicing the reqauest no? just like it always was really.
I always thought a part of CORS's mission is to prevent DDOS attacks too.
If someone tries to use millions of peoples browsers as a botnet, the worst they can do is shower the target with cheap HEAD requests.
But I am far from an expert.
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
why are we trusting the browser for security?
Because we remember the world when browsers had no security.
We trust the browser with security, a piece of software running on an unknown system by an unknown user that may or may not be doing what it says it is doing because we remember when they didn't have security?
yeaaaaah.
that makes sense.
I'mma going to code my server to trust the browser exactly as far as it can throw it.
You, as a web app builder, cannot trust the browser with security. You can only hope that the end user is the same person as claimed in cookies or tokens if they appear to be untampered with and they appear to come from the right source, but other than that there's no guarantees.
You, as an end user of the browser however, would like that the browser applies the concept of least-privilege with your cookies or tokens so that one malicious script on one website can't suddenly steal the cookies of your BookFace or HipsterBank account which are on different website locations. There's all kinds of ways in which this security might be compromised (extensions! burn 'm!) but you'd still like for some level to be there out of the box.
GET requests may still not be safe to be executed as a malicious script may try to grab a cookie and convert it into a token passed in a query parameter or URL Authority part.
-
@blakeyrat That would be Chesterton's Fence:
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
It's a good principle that many people all over the world need to take to heart.
-
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
I'm sticking with my original advice: contact them somehow and ask "what's the dealio?"
The lengths some software engineers will go to to avoid talking to another human being is crazy to me.
And then there's me. If I have an issue, I'll go to "lengths" to find a real human being to talk to about it even if it would be easier to just find something kicking around on a forum from 3 years ago.
Maybe I'm just weird like that?
-
@accalia said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
why are we trusting the browser for security?
Defense in depth. Next question?
-
@darkmatter said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
Host a 3rd site with a curl call to the 2nd site that parrots that info back to you with CORS enabled, then you can call that from the 1st site
I'd stand up a proxy using nginx (which would give a number of options for more subtlety than just running curl as a cgi) but it's the same basic idea: get a server somewhere (which isn't a browser and isn't subject to browser security rules) that can see everything needed and tell the webapp about it. You can run different credentials between all the pieces, locking out unwanted visitors (if you want), poke holes in firewalls to the specific address, all that jazz. But you need that server; it can be the cheapest hosting ever (or not, depending on what sort of traffic levels there are) but it's critical for fixing everything. You can even get it to slap on CORS headers if you want; I never bothered since I was happy just aggregating everything (and doing so solved other problems too) but it would be trivial to do.
Joining everything without a server and with uncooperative sources is what the web won't do.
-
@Benjamin-Hall said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
It's a good principle that many people all over the world need to take to heart.I like that! I'll have to keep that one in mind for future use! :D
-
@Yamikuronue said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@blakeyrat said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
contact them somehow and ask "what's the dealio?"
I just so rarely get useful answers when I do that even with paid support contracts that I rarely bother with free services.
Back when I was dealing with such things, we made a proper API be a required condition of using the service and flat out told the vendors as we moved into the later stages of the shortlisting process. Several very expensive vendors got very upset when we told them to get stuffed over their failure in this area. :)
(Don't need that stuff at the moment; I'm contracted onto a very different type of project.)
-
@Benjamin-Hall said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
That would be Chesterton's Fence:
Too bad Chesterton was the opposite of pithy.
-
Have you solved the issue? I have a suggestion that might be unhelpful regardless, but I'm going to say it anyway:
You could try implementing a low-tech version of jsonp yourself. If you have a javascript that looks like this
var data = download('http://a.b/datafile'); use(data) ;
Add a step to your build process generates a javascript where the download is replaced by literal containing the contents of that datafile. So if for instance your datafile contained the text 'hello world', your generated script would look like
var data = 'hello world'; use(data);
-
@Buddy said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
You could try implementing a low-tech version of jsonp yourself.
that is what i am doing now, yes.
i'm still looking into alternatives though as this result is unpalitable and means i have a hard time detecting certain failure states, if i even can (not all browsers support
onerror
on script tags)appveyor is looking into enabling CORS but until then.......
-
@accalia oh yeah, I actually remember reading that post now, sorry. I think I might have a bad habit relating to dollar-sign variables, where I assume that people are talking php so I just move on the next post.
-
@buddy said in No 'Access-Control-Allow-Origin' header is present on the requested resource.:
@accalia oh yeah, I actually remember reading that post now, sorry. I think I might have a bad habit relating to dollar-sign variables, where I assume that people are talking php so I just move on the next post.
PHP, PowerShell...... close enough!