mybinder.org, being free anonymous compute, is vulnerable to abuse, especially by cryptocurrency miners. We have various measures to prevent abuse, but given the permissive nature of Binder’s spec, that often means identifying patterns of abusive behavior and disabling them, which can catch legitimate use in the net.
The latest pattern we have identified is automating requests originating from datacenters, especially AWS. As a result, we are going to start blocking launch requests coming from known datacenters (AWS, Google, Azure). This means, for example, that you won’t be able to request new binder launches from within binder itself.
The downside: There may be legitimate use cases that stop working! If you see an error like “Requests from AWS are not allowed”, let us know what you are trying to do and we’ll see if there’s something we can solve.
Stumbled across this and wondering if you can assist with my use case.
I run coffee and coding sessions where we utilise Binder for a small group of 15-30 learners. I am trying to use a commit to master as a trigger for an initial binder build / launch to automate the first build and ensure everything is always up to date.
We are forced to host in GitLab.com and you can find the repo here.
Upon running .gitlab-ci.yml and invoking trigger_binder.sh, the response is:
Although it looks like the CI passes it doesn’t, as the build is blocked due to the GitLab CI coming from Google Cloud (I guess)?.
Is there a fix for this or another way I can automate this?
We’re actively investigating how to make it less disruptive to genuine users, but in the meantime you could look at using repo2docker-action to pre-build your docker image and push it to a registry that your binder repo could then reference:
