This PR modifies our privatisation flow to also include netlify repos. Previously, we realised that sites we migrated to amplify still retained their associated netlify repo (as a backup), and we were building to both netlify and amplify. This means that it is theoretically possible for a user to access content on a privatised repo via the link to the netlify site, if the user was able to obtain it.
To fix this, this PR introduces functionality to also modify the build on netlify. Specifically, we take the following actions on the netlify build, for any site which builds from the staging branch of the desired repo:
We change the password to the one first provided by the user
We disable automated builds for this repo in future
As we're keeping the netlify repo only for emergency uses, we can simply reenable the builds if we ever need to use it.
As we do not store the link to the netlify repo anywhere in either the github repo or our db, the only way to locate the netlify repo is to retrieve the full list of netlify repos we control, and filter this down via inspecting the connected repo. As this is a slow operation, I've opted to make this as an async operation that we do not await, and call only when sites are changed from a public to private repo, in order to minimize the number of times this is called. However, this means that the password on the netlify site may not match up with the password on the amplify site - I feel like this is acceptable as we are still able to access the netlify password via the netlify UI, and the netlify site is unknown to the users.
New environment variables
NETLIFY_ACCESS_TOKEN: this is the access token we use to access our account. We should be using the one generated for isomeradmin
This PR modifies our privatisation flow to also include netlify repos. Previously, we realised that sites we migrated to amplify still retained their associated netlify repo (as a backup), and we were building to both netlify and amplify. This means that it is theoretically possible for a user to access content on a privatised repo via the link to the netlify site, if the user was able to obtain it.
Video for full user flow is on https://github.com/isomerpages/isomercms-frontend/pull/1316
To fix this, this PR introduces functionality to also modify the build on netlify. Specifically, we take the following actions on the netlify build, for any site which builds from the staging branch of the desired repo:
As we're keeping the netlify repo only for emergency uses, we can simply reenable the builds if we ever need to use it.
As we do not store the link to the netlify repo anywhere in either the github repo or our db, the only way to locate the netlify repo is to retrieve the full list of netlify repos we control, and filter this down via inspecting the connected repo. As this is a slow operation, I've opted to make this as an async operation that we do not await, and call only when sites are changed from a public to private repo, in order to minimize the number of times this is called. However, this means that the password on the netlify site may not match up with the password on the amplify site - I feel like this is acceptable as we are still able to access the netlify password via the netlify UI, and the netlify site is unknown to the users.
New environment variables
NETLIFY_ACCESS_TOKEN: this is the access token we use to access our account. We should be using the one generated for isomeradmin