De faire reposer tout sur le logiciel, oui ça serait naze.
Mais d'une part, il n'y avait sans doute pas plus de limites sur le reverse proxy (donc le propos reste valable). Et d'autre part, ça n'est pas un ou exclusif, tu peux faire ça au niveau tcp et http(s) et du logiciel.
Et dans le cas de Gitea, Gogs et Forgejo, la philosophie de est d'avoir un tout en un.
Par exemple, Gitea supporte de faire directement la négo avec Let's encrypt. Woodpecker et Gotosocial le propose également. Alors c'est peut être parce qu'ils sont tous en Golang, et qu'il y a une lib qui permet de faire ça facilement, mais ils sont tous aussi dans le segment des logiciels simples pour faire du self hosting, facile à déployer (tu prends le binaire, tu lances), etc.
Perso, ça m'horripile un peu, mais je comprends bien que ça facilite la vie de pas mal de gens. Ajouter un reverse proxy, ça complique tout de suite pour les gens qui n'ont pas notre niveau d'expérience.
Et cette philosophie se retrouve ailleurs dans ces logiciels. Gitea gère ses taches périodiques sans passer par cron, dans son propre process. Pour des applis django ou rails, tu te retrouves souvent à mettre celery ou sidekick à coté.
Et même si faire ça sur le reverse proxy a du sens pour éviter les DoS, je pense que d'un point de vue plus général, la limitation dans le logiciel complémente le filtrage du proxy en ayant une vision à un niveau différent. Par exemple, tu peux imaginer que l'envoi de notification soit plus important à limiter qu'un appel qui va scraper les user id d'un repo (ou la gène est bien plus minime). Le premier va vite être louche alors que le second est sans doute bénin.
Avoir ça dans le logiciel permet aussi d'assigner des exceptions de façon fine pour des besoins spécifiques. Pour reprendre l'exemple de savoir qui a accés à quoi, une équipe de sécurité pourrait vouloir chercher l'info via l'API et donc avoir un besoin légitime. Avoir ça dans le logiciel, ça permet d'avoir un rapport et la config dans l'interface d'admin, ou de bloquer directement le compte qui abuse au lieu de devoir faire du matching depuis des logs qui n'ont pas l'info de qui est en cause. Tu peux avoir les notifications du logiciel out of the box.
Bien sur, avec un bon reverse proxy ou un SIEM, tu peux avoir tout ça (et dans certains cas, c'est sans doute la bonne solution). Mais c'est pas le même prix et/ou la même complexité.
[^] # Re: Subtance
Posté par Misc (site web personnel) . En réponse au journal L’extrême droite s'en prends à Codeberg. Évalué à 7.
De faire reposer tout sur le logiciel, oui ça serait naze.
Mais d'une part, il n'y avait sans doute pas plus de limites sur le reverse proxy (donc le propos reste valable). Et d'autre part, ça n'est pas un ou exclusif, tu peux faire ça au niveau tcp et http(s) et du logiciel.
Et dans le cas de Gitea, Gogs et Forgejo, la philosophie de est d'avoir un tout en un.
Par exemple, Gitea supporte de faire directement la négo avec Let's encrypt. Woodpecker et Gotosocial le propose également. Alors c'est peut être parce qu'ils sont tous en Golang, et qu'il y a une lib qui permet de faire ça facilement, mais ils sont tous aussi dans le segment des logiciels simples pour faire du self hosting, facile à déployer (tu prends le binaire, tu lances), etc.
Perso, ça m'horripile un peu, mais je comprends bien que ça facilite la vie de pas mal de gens. Ajouter un reverse proxy, ça complique tout de suite pour les gens qui n'ont pas notre niveau d'expérience.
Et cette philosophie se retrouve ailleurs dans ces logiciels. Gitea gère ses taches périodiques sans passer par cron, dans son propre process. Pour des applis django ou rails, tu te retrouves souvent à mettre celery ou sidekick à coté.
Et même si faire ça sur le reverse proxy a du sens pour éviter les DoS, je pense que d'un point de vue plus général, la limitation dans le logiciel complémente le filtrage du proxy en ayant une vision à un niveau différent. Par exemple, tu peux imaginer que l'envoi de notification soit plus important à limiter qu'un appel qui va scraper les user id d'un repo (ou la gène est bien plus minime). Le premier va vite être louche alors que le second est sans doute bénin.
Avoir ça dans le logiciel permet aussi d'assigner des exceptions de façon fine pour des besoins spécifiques. Pour reprendre l'exemple de savoir qui a accés à quoi, une équipe de sécurité pourrait vouloir chercher l'info via l'API et donc avoir un besoin légitime. Avoir ça dans le logiciel, ça permet d'avoir un rapport et la config dans l'interface d'admin, ou de bloquer directement le compte qui abuse au lieu de devoir faire du matching depuis des logs qui n'ont pas l'info de qui est en cause. Tu peux avoir les notifications du logiciel out of the box.
Bien sur, avec un bon reverse proxy ou un SIEM, tu peux avoir tout ça (et dans certains cas, c'est sans doute la bonne solution). Mais c'est pas le même prix et/ou la même complexité.