Human validation download

[Xpirix]

This is the proposed fix for #402

Cc @timlinux @Gustry @Guts @benz0li

Changes summary

• Restrict direct download to QGIS User-agent for now. I suggest using a common User-agent for those who want to use the direct download like "Mozilla/5.0 Plugins Direct Download" for example.
• Set NGINX rate limit for each IP address to 10 requests/second
• Create a new endpoint for web download
• Add a human validation when downloading from the web: plugin name confirmation
• Add a delay of 3s for the web download before it starts
• Set the web download rate limit for each IP address to 10 downloads/minute by default. We can increase or decrease it through the environment variable. This feature is using Django cache.

I was wondering if we also want to apply a download rate limit for the direct download. Note that it will impact QGIS and other applications that are using it.

Please find below a screen record of the web download feature (I've set the download rate limit to 2 here):

https://github.com/qgis/QGIS-Django/assets/43842786/6a4c7cb1-bd71-41e6-8bd5-562edc46ec1c

[Guts]

Restrict direct download to QGIS User-agent for now.

If you deploy that every script/tool downloading plugins for right purpose will be broken.

Is it possible to implement right now a white-list? I've read more about user-agents and it seems that a bad idea to encourage different tool to have the same.

[timlinux]

Restrict direct download to QGIS User-agent for now.

If you deploy that every script/tool downloading plugins for right purpose will be broken.

Is it possible to implement right now a white-list? I've read more about user-agents and it seems that a bad idea to encourage different tool to have the same.

hi @Guts

Thank you for your comments here and in the original issue. For now I want to suggest that you emulate the plugin manager UA to bypass this limitation. For the longer term, we can add an api and api key system to allow automation like you want to do without need for UA hacks. Please bear in mind that we have limited resources and the intended use case for the plugin repo is to make the plugins available via the plugin manager inside of QGIS. IMHO other use cases should be discussed first with us and the proposer should make sure that we have adequate resources (e.g. sponsoring additional servers) if needed.