Closed ghost closed 10 years ago
sprry about that let me look into this, this CORs issue keeps popping up :)
I know, man, it's weird. Maybe a Heroku setting or something?
Also, you should make a pull request to your fork to pull in the last two direct commits: 0c68856279d665a08f54229b7e33c00a9cc4ab5d and 6d15451a70b072376b837c9a034009e802d0518e.
what are the headers saying if you dont mind me asking? that will probably give me a hint,
cool that it works locally.
Not sure how to check that. Tips?
EDIT: Nevermind. For http://norfolkart.herokuapp.com/exhibits:
HTTP/1.1 200 OK =>
Access-Control-Allow-Origin => *
Content-Type => application/json; charset=utf-8
Date => Wed, 25 Jun 2014 17:30:39 GMT
Etag => W/"881f-3515093840"
X-Powered-By => Express
Content-Length => 34847
Connection => Close
EDIT EDIT: Used the following site to get the above headers.
EDIT EDIT EDIT: Also, I think it works locally because it's the same domain and all, so it doesn't help with the cross-domain checks at the moment, but yeah, the RESTAdapter
works really nicely, actually. :smiley:
Interesting: using the following curl command:
curl -i -H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-X OPTIONS 'http://norfolkart.herokuapp.com/exhibits'
...the following headers display:
HTTP/1.1 204 No Content
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Access-Control-Allow-Origin: *
Date: Wed, 25 Jun 2014 18:22:31 GMT
X-Powered-By: Express
Connection: keep-alive
"No content?"
Finding out that Firefox, due to handling pre-flight CORS requests properly, will not load the resultant page, while seemingly every other browser out there (I tested on IE, Opera and Chrome) will not handle the HTTP 401 from the pre-flight request properly and just load the page anyway.
I would suggest we find a way to handle the pre-flight request without authentication as the article suggests, using Node.js, of course.
Hey @stanzheng, I just committed 1c2292cf02dac4bbd6bf9ea3139f69504889e959, mind pushing that to Heroku when you get the chance? If it doesn't function, we can always revert it.
I looked up the docs and i thought the
app.use() synthax applies it to all the routes.
https://github.com/c4hrva/proxy-art/blob/1c2292cf02dac4bbd6bf9ea3139f69504889e959/server.js#L27
But i send it upa nywhere
On Wed, Jun 25, 2014 at 2:54 PM, Ryan Y. notifications@github.com wrote:
Hey @stanzheng https://github.com/stanzheng, I just committed 1c2292c https://github.com/c4hrva/proxy-art/commit/1c2292cf02dac4bbd6bf9ea3139f69504889e959, mind pushing that to Heroku when you get the chance? If it doesn't function, we can always revert it.
— Reply to this email directly or view it on GitHub https://github.com/c4hrva/proxy-art/issues/13#issuecomment-47143123.
Spam https://www.spamtrap.odu.edu/canit/b.php?i=02MiGSObf&m=56807f5ff2d1&t=20140625&c=s Not spam https://www.spamtrap.odu.edu/canit/b.php?i=02MiGSObf&m=56807f5ff2d1&t=20140625&c=n Forget previous vote https://www.spamtrap.odu.edu/canit/b.php?i=02MiGSObf&m=56807f5ff2d1&t=20140625&c=f
Stanley Zheng @stanzheng http://twitter.com/stanzheng
:laughing: We could likely not worry about the last couple of commits. I looked at NoScript and RequestPolicy. They both blocked the norfolkart.herokuapp.com
domain.
I'm a big dumb-dumb. Closing!
_Redacted too lame_
I don't understand the question.
oh * i never pulled down and tested the c4hrva/NorfolkArt app myself so i didn't do my due diligence for app development.
:laughing: I understand, man. It all seems to work properly now, though.
It does seem to take a bit for the gh-pages changes to propagate to the domain we set up... still can't see the live changes for http://iartnorfolk.com/ yet.
Just tested the RESTAdapter for iArtNorfolk with a local instance of proxy-art as of commit 0c68856279d665a08f54229b7e33c00a9cc4ab5d and it functions properly:
Testing the RESTAdapter using the heroku instance fails to load the same route:
Not sure if we actually have cross-domain access for the data here, nor how to handle this.