PSA: Public demo server (cors-anywhere.herokuapp.com) will be very limited by January 2021, 31st #301
Comments
|
As announced, the public demo has been restricted. If you are developing a new web application and want to try out CORS Anywhere, visit https://cors-anywhere.herokuapp.com/ and click on the "Request temporary access to the demo server" button, to temporarily restore the full functionality of CORS Anywhere for your client only. |
|
i have message "You currently have temporary access to the demo server." but still not working |
|
@rizkhal Please file a new issue if you encounter what you think is a bug, and include details / reproduction steps. |
Same issue. I go to |
Again: please file an issue with exact reproduction steps. 403 can also be the result of something else (e.g. it being the real reply). I cannot resolve the issue unless you share the steps/URL/code/commands to reproduce the issue. |
|
You currently have temporary access to the demo server., but not wirking |
|
I have just published an update to the demo server to improve the detection of a "client". Previously, Heroku routers were mistakenly identified as the "client", with the fix the actual clients are identified instead. |
|
Thanks for the PSA, was wondering why I was getting errors lol. This service was super useful to me and I am able to run it locally for a personal project. Am experimenting with hosting it on my own server. Appreciate your work on this project!! |
|
Hi Rob. Yesterday I requested temporary access via the button located at '/corsdemo'. This got my app working again, though today I had to go through the process again. Is frequently re-requesting access the intended behaviour? For development purposes this is not an issue, but in production a user couldn't be expected to do this of course. I'm just using the app as a portfolio project by the way, with very little traffic. |
|
So what should I do to host cors-anywhere on my server? Documentation is very far from being clear. |
|
What can I do to use this in production? Is it just me to publish this project and use the url in front of my api? |
This is intended. The announcement here and the page where you request access very clearly states that access is temporary. The public demo is identical to the source code in this repository, except with additional routing logic in front to verify that access is permitted. The access is regularly revoked (currently 1-2 times per day, sometimes more if the server is overloaded).
Previously, the demo server was open to everyone by default. Due to the abuse, the service was often slow or unavailable, which made it a bad service to rely on for portfolio sites. I have once received a request from a student to help them with recovering their grade after their application failed when the public demo was unavailable. These kinds of scenarios can only be avoided by very clearly making the demo opt-in. For prototyping purposes (e.g. a demo project or an example on a portfolio), you could link to the
This project is a library that can be used to create a CORS proxy server. The project ships with a sample, I occasionally see people forking the project and removing
The relevant files are referenced at Lines 23 to 29 in 528ad71 If you don't care about the unit tests, then lib/ and server.js can be copied.It may be easier to clone the repository and occasionally fetch new changes. The public demo runs off a fork of the master branch of this repository.
The server address (scheme + host name + port) on which the CORS Anywhere proxy is running.
See the "Demo server" documentation, or edit server.js to have custom logic if the sample doesn't fit your needs.
The hosting platform needs to be able to run Node.js.
If you want to operate an open proxy, then yes. If you want to apply restrictions, see my other remarks in this comment. |
|
Thanks for getting back to me. I'll give self hosting a go and and if I can't manage it just redirect to the |
|
Thanks for the hard work you have put in this, really remarkable job, I've mounted now a self-hosting instance, but really appreciated your openness before the headsup to close the service! much <3 |
|
Hey Rob, thank you very much for all your documentation and updates. I was using cors-anywhere in my fetch api directing towards the Yelp Fusion API, and querying results into a personal project app on my portfolio. I'm doing everything strictly on the Front End (don't know how to do this on the backend yet), is there any other options you could recommend to solve this issue around the No 'Access-Control-Allow-Origin' header? Thanks again |
The best solution is to ask your API service provider to support CORS. There appears to be a pending feature request, without recent activity though: Yelp/yelp-fusion#64 PS. To everyone who is considering to post a new comment here - Please file a new issue if you have questions that are unrelated to the announcement here. This issue should only be used for comments related to the announcement. |
|
I have found a useful replacement |
|
Hi guys any idea what we can use beside the above Thanks |
|
@Corey-Wademan |
|
Hello i used this solution on dynamics crm 365 ,for this issue any update for the managed solution ? thanks |
|
Hi there, I see some of you are looking for a replacement to cors-anywhere. Don't waste your time searching for a better tool: just deploy your own instance to Heroku (free dyno). It takes 5 minutes. 10 minutes if you need to create a Heroku account 😊 |
The custom filtering logic is not part of the public repository, to keep the project clean.
It can work,but not good. |
|
Hi, I have tried this and it is working completely fine for me. but this is a temporary solution. Thanks. |
* Extend supported Node.js from <=9 to <=14 * test-memory: destroy response to free socket Starting from Node 12, the test started to fail because of intermittent socket errors, such as ECONNRESET and "socket hang up". Destroying the response before triggering a new request resolves it. * Explicit early out for invalid URLs * Version 0.4.2 - Reject invalid URLs earlier instead of trying to continue with the request (and failing anyway). - Explicitly close the response when an error occurs for Node 13+. - Update tests to cover up to Node 14 (was up to 9). * Update test expectation for Node 12.x * test-memory: fix test by passing --max-http-header-size The test broke because Node lowered the maximum header size to defend against large headers ( CVE-2018-12121 ). In the test, we do actually want to pass large headers, because all processing in CORS Anywhere is based on headers (the request body would just be forwarded to the destination server). The test failed intermittently with ECONNRESET or "socket hang up" because the server (under test) would close the socket upon receiving a request with too large request headers. * Pass --max-http-header-size in supported versions only * Reject invalid redirects Fixes Rob--W#234. * Version 0.4.3 - Reject invalid URLs in redirects (fixes regression from 0.4.2) (Rob--W#234) - Update memory tests for recent Node versions. * only send Access-Control-Max-Age if preflight request, not POST/GET -Access-Control-Max-Age header only has meaning for preflights, not POST or GET, saves wire bytes by excluding it from POST/GET/etc, and future problems if ACMA on a content HTTP method is given meaning by W3C or a browser vendor -fix expectNoHeader() test helper func ,this was a no-op before by accident and would NEVER fail, supertest/test.js:Test.prototype._assertFunction requires an retval of class type Error if test fail, not a string or a number or Object * remove Heroku specific Req headers from being sent to Origin -saves bytes, and avoids triggering IDS/WAF alarms since browser finger printing will prove these headers are unnatural and on SSL must be a MITM attack -leave x-forwarded-* intact since they can be used to block CORS proxy abuse if the not-CORS origin webmaster really has to block the proxy and they are not unique to Heroku platform * Remove obsolete values from server.js's removeHeaders `X-Heroku-Dynos-In-Use`, `X-Heroku-Queue-Depth` and `X-Heroku-Queue-Wait-Time` have already been dropped in 2013: https://devcenter.heroku.com/changelog-items/218 * Add handleInitialRequest option to support Rob--W#301 The custom filtering logic is not part of the public repository, to keep the project clean. * Expand handleInitialRequest documentation Rob--W#335 * Add note about availability of public demo server Referencing Rob--W#301 * Update gTLD list * Version 0.4.4 - Omit unnecessary `Access-Control-Max-Age` (Rob--W#277) - Remove more Heroku-specific headers (Rob--W#278) - Add `handleInitialRequest` option (Rob--W#335) - Document access requirements for public demo (Rob--W#301) - Update gTLD list * Support NODE_TLS_REJECT_UNAUTHORIZED=0 to ignore client errors Rob--W#341 Apparently `NODE_TLS_REJECT_UNAUTHORIZED` is only effective if `rejectUnauthorized` was not overridden by the code: https://github.com/nodejs/node/blob/85e6089c4db4da23dd88358fe0a12edefcd411f2/lib/_tls_wrap.js#L1583-L1591 But the underlying library does override it: https://github.com/http-party/node-http-proxy/blob/v1.11.1/lib/http-proxy/common.js#L53-L55 Fix this by overriding the option via the library's "secure" option. * Fix test expectation for old node * Migrate travis-ci from .org to .com * Add Node 15.x to Travis * Show "400 Missing slash" when needed Rob--W#238 * Add LICENSE file based on README.md Rob--W#297 * Fix typo Co-authored-by: Rob Wu <rob@robwu.nl> Co-authored-by: bulk88 <bulk88@hotmail.com> Co-authored-by: Noodles <20896419+alex-lushiku@users.noreply.github.com>
|
The demo just whitelists the user's IP address when the request access button is clicked, right? Any reason you don't implement a CAPTCHA, or two, to avoid abuse? Maybe as a long term goal either an API key, an encrypted string containing the expiration timestamp, or a JSON Web Token could be implemented in the project itself. I could see myself using that. I have an implementation of Any of those could be sent either in the request URL or in the request headers.
AES Encryption and Decryption Demo |
Temporarily, yes.
Captcha does not offer more than what my implementation of the button already does.
You're free to implement that, but that would be a change in the API of this project. The key behind this project is its simplicity for clients: just prepend the proxy URL before a cross-origin URL, and the (public) resource can be read. |
|
Here is my own proxy server https://fast-dawn-89938.herokuapp.com/ Have a good day! 😊😍 |
@Rob--W Protocol question: Are comments like the above welcomed and appropriate on this post? It kinda seems like McDonald's advertising in Burger King's parking lot. |
On-topic knowledge to help others with addressing problems are welcome. Spam is not welcome and will be deleted. At this point this thread has many subscribers, so I kindly request everyone to think twice before posting another comment. |
Have you set up a paid version of this where you could keep track of any abusers and ban them if they pay and then abuse? I only know enough coding to get myself in trouble and I have to get temporary access daily to run an app we will probably be using several times a week. Thanks! |
|
See #434. |
|
I am not having any issue with the cors. Mine one is working fine |
|
@Rob--W Thanks a ton for making this available. Hosting my own now, but this demo and your instructions have been super helpful for getting set up. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@chrahman the link is not working |
|
That was likely using free hosting, as seen in #434. I am paying for the hosting of cors-anywhere.herokuapp.com, which is therefore still up. |
|
@Rob--W Maybe you should add a donate button? |
|
Here is my hosted fork for this project: https://cors-proxy.fringe.zone/ |
Please I need a process on how to host and whitelist my site only. |
|
I made a thing of slight evil. https://github.com/xriss/security-theater Browser extension that hijacks the cors-anywhere url at the "fetch" level. Works on chrome etc but not firefox as firefox does not support v3 extensions, (yet?). Not quite the same as the other cors extensions that patch http headers, this patches in page javascript and uses cors-anywhere as a trigger then passes the request into the extensions worker. The idea is, install extension and you can use cors-anywhere.herokuapp.com without hitting the server and causing any bandwidth costs, don't install extension and you get an obvious intent to use some sort of cors proxy. Is this a good idea? Not sure... |
thankyou |
I am trying the for calling circleCI from testrail. With your https://cors-proxy.fringe.zone/ it just works fine but if I host my version on heroku it gives cors , do you know the reason? I just fork your repo and deployed it on heroku |
|
Would any developers be willing to pay for a cors proxy? Maybe on a metered billing by the number of requests they make? |
|
Payment is not the problem here. I am already footing the bill for keeping the server online. The problem is that the hosting platform does not want to support an open proxy due to abuse risks. |
It's not a common request. And there is already some solutions on the market offering same thing. Much easier to make wrapped api on the server if you have access. |
Could you pls tell how to depoy this over netlify for free to make our own custom proxy? |
|
is very helpful |
|
I understand many of you are experiencing issues with the limited functionality of the
Remember, the demo is intended for development and testing, not for production use. |
|
RIP brother thank you for your service |
No :O I just started using this and wanted to pay my dues to the golden age |
|
To add to anyone who doesn't know where to get started, you can very easily make a fork of this repo and deploy it directly from Vercel. Took me about 3 minutes. |
|
Can you provide a permanent usage to this solution |
and others
The demo server of CORS Anywhere (cors-anywhere.herokuapp.com) is meant to be a demo of this project. But abuse has become so common that the platform where the demo is hosted (Heroku) has asked me to shut down the server, despite efforts to counter the abuse (rate limits in #45 and #164, and blocking other forms of requests). Downtime becomes increasingly frequent (e.g. recently #300, #299, #295, #294, #287) due to abuse and its popularity.
To counter this, I will make the following changes:
What should current users of CORS Anywhere do in response to this announcement?
If possible, try to avoid the need for a proxy at all. CORS Anywhere works by combining proxy functionality with CORS. You may not need proxy functionality, if the web service that you are trying to access already supports CORS. This is the preferred solution because it is faster and more reliable. For development, you can also consider the use of browser extensions that automatically enables CORS for certain websites.
If your use of CORS Anywhere is infrequent, then the exception from step 3 above will allow you to continue as before. The only difference is that you need to explicitly opt in before access is temporarily allowed. If you'd like to not have these restrictions, then you should self-host CORS Anywhere.
For an example of self-hosting, see https://github.com/Rob--W/cors-anywhere#demo-server . There are also many questions and answers about hosting on the issue tracker here (https://github.com/Rob--W/cors-anywhere/issues). If you have questions, please search for existing issues first before opening a new issue.
The text was updated successfully, but these errors were encountered: