You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following last night's request storm from @echoix we need to look at how best to throttle/limit the refreshes.
We cannot afford for a potentially well-intentioned user from clicking request refresh on every node again. Last night's 240 refresh storm almost caused an outage. Any mass update has to be done in a much more controlled manner.
This morning I added csrf protection to the refresh endpoint to make it harder for someone to script a mass update.
One option to consider is to limit the ability to refresh a node to users who have some association with the module. We do let users link their GitHub and npm accounts already, but that does add more steps for a node author to get their node refreshed.
Another option is to add a background task that slowly checks each node for any update - doing it at a slow pace to ensure we don't abuse the npm API and end up getting blocked. Although this wouldn't stop someone from clicking the refresh request on lots of pages, it would avoid things getting out of date.
(@echoix just to be clear, please stop clicking refresh)
The text was updated successfully, but these errors were encountered:
Certainly, I won’t be refreshing! It was not scripted at all, made manually. New user to Node-RED, found out that one of the packages I wanted to use had been fixed, published to npm, but the bad version was available in the flow palette. When I found out why the package wasn’t kept up-to-date, I was kind of frustrated that some packages were so outdated since the API stopped updated in April. So I opened up the npm web page, searched for node-red-contrib, and entered the names of the packages last updated mostly in the last 2-3 months.
Since no script was doing it, I did it manually. Since I didn’t see a lot of seriously maintained packages, I didn’t believe all the maintainers keep them updated. I got tired after the 26 first pages, since the npm website can’t sort by last updated.
So, there shouldn’t be many more to update left, but leaving up to you then ;)
No bad intentions at all :)
Oh, and my internet is unreliable, so it crashes often.
Following last night's request storm from @echoix we need to look at how best to throttle/limit the refreshes.
We cannot afford for a potentially well-intentioned user from clicking request refresh on every node again. Last night's 240 refresh storm almost caused an outage. Any mass update has to be done in a much more controlled manner.
This morning I added csrf protection to the refresh endpoint to make it harder for someone to script a mass update.
One option to consider is to limit the ability to refresh a node to users who have some association with the module. We do let users link their GitHub and npm accounts already, but that does add more steps for a node author to get their node refreshed.
Another option is to add a background task that slowly checks each node for any update - doing it at a slow pace to ensure we don't abuse the npm API and end up getting blocked. Although this wouldn't stop someone from clicking the refresh request on lots of pages, it would avoid things getting out of date.
(@echoix just to be clear, please stop clicking refresh)
The text was updated successfully, but these errors were encountered: