-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running on Heroku with one-click deploy #320
Comments
To minimize backwards-incompatible breakage and confusion, I'm not going to accept the "black"/"white"->"allow"/"block" change. Documentation for the Heroku one-click deploy feature is at https://devcenter.heroku.com/articles/heroku-button A completely open proxy is against Heroku's Acceptable Use policy. The current version of your PR makes the proxy open by default. Is it possible to require explicit action from developers, so that whoever that wants to use the button knows that they have to change the configuration? |
It's written on the screen and in your docs. I've added to only have localhost in the allowlist and 1 1 in the rate limit. This seemed to block unwanted traffic. |
Regarding backwards compatibility for black/block type change, might I suggest supporting "blackList" and "whiteList" as aliases? Eg: If both |
Right there is a branch at https://github.com/Lewiscowles1986/cors-anywhere/tree/chore/backwards-compat-uninclusive-terms which does this, and console warns on use of the deprecated properties. Logic is:
Perhaps this removes the rejection of the rename. I'm just not happy using those terms, but I understand the need to roadmap changes. I Have opted not to document the alias. New users should not really be choosing to deliberately use discriminatory language. It is also not part of the Heroku one-click as that is similarly a greenfield, rather than for existing users. |
RE: comments on [Issue Rob--W#320][1] Make a path to move to more progressive terminology. [1]: https://github.com/Rob--W/cors-anywhere/issues/320#issuecomment-801445034
RE: comments on [Issue Rob--W#320][1] Make a path to move to more progressive terminology. [1]: https://github.com/Rob--W/cors-anywhere/issues/320#issuecomment-801445034
@Lewiscowles1986, after I 1-click deployed from your repo's, I got an empty repo when I |
Hey Bob, Sorry to hear you've had that difficulty. Could you share some more information about your setup? I Just did the same thing both from my main branch and the branch I linked here, and both are working for me in Chrome, Firefox, Edge and Safari (all latest) across Windows, Linux and OSx. Did you need to login to Heroku first? I Do know that deploying from app.json does not automatically setup deploy from git commits. I think if I point it at my repository, then there would be more of a problem merging as it would be hosted here, but point to a potentially out-of-date branch, rather than official cors-anywhere. |
The deploy worked fine. I clicked the button and got a screen asking for the environment variables. I was able to deploy the app to heroku as "myApp" After it deployed and was running, I used the heroku cli and did |
As mentioned @bobpaul once merged upstream this could be a thing. Right now it would make me an unofficial maintainer of something I only encountered when helping a friend. I saw some problems (for us), and came up with a solution to fix them, and then offered what we had. It sounds like a great suggestion for a next step. I Think if we could get this merged first, then it would be easier to make a tiny patch referencing this comment on this issue. I'll add it to the top as an action item. |
I'm planning to prepare a new release soonish (but not urgent), and am considering to accept the requested functionality. The branch is doing too many unrelated things. Could you split it in separate pull requests so that they can be reviewed and merged independently? Please keep the number of unnecessary changes to a minimum (and have meaningful commits; otherwise I would need to squash them all into one commit). I suggest the following order (the Heroku one-click deploy last because it depends on the renamed variable).
I'm not sure what you mean by "suggested improvement. Specify repository, so source code updates can ship to heroku and heroku local-machine git can be used.". Why is that part of your branch? FYI: My heroku demo runs a fork of the master branch (with patches on top to enforce restrictions to comply with the policy). That use case should not be endangered by the proposed changes. |
RE: comments on [Issue Rob--W#320][1] Make a path to move to more progressive terminology. [1]: https://github.com/Rob--W/cors-anywhere/issues/320#issuecomment-801445034
Hi, I have the following code: how can I fix the 403 (Forbidden) error? |
@Lewiscowles1986 I just noticed that you added a commit there, but there is no open pull request to review. If your patches are ready for review, please open a PR. @pierre1590 Your question is unrelated to this issue, please don't post unrelated comments on random issues. For your specific issue, see the pinned issue for the explanation. |
In order to run on Heroku with one-click deploy, I setup a fork https://github.com/Lewiscowles1986/cors-anywhere
If Rob wants it, I'm happy to upstream and I kept each branch alive so I can rebase on their repo. I made some other choices too, such as renaming some bits and enabling CI.
This issue is here as "documentation" of how to setup your own cors anywhere using Heroku.
Summary of discussion of changes
The text was updated successfully, but these errors were encountered: