On héberge un petit groupe d’instances Nextcloud (v30.0.5) avec le fork de collabora tiredofit/docker-collabora-online (dernière version) et l’app Nextcloud Office (dernière version).
Ces derniers temps, il semblerait que le client web de l’un·e de nos utilisateur·ices se mette à spammer complètement Nextcloud au cours de la consultation d’un document Collabora :
C’est uniquement la route /avatar/ sur Nextcloud qui se fait spammer, pour a priori récupérer le même avatar… Comme vous pouvez le constater, on a mis en place un rate limit (d’où le code de statut 429), mais sans rate limit le résultat est le même.
Le client réalise environ 300 requêtes en l’espace de 15 secondes.
Ce comportement semble se reproduire sur différents navigateurs.
Côté utilisation de ressources, ça s’est passé comme ça :
Il n’a pas fallu plus de quelques minutes pour faire tomber l’instance Nextcloud en boucle (out of memory).
Vous avez déjà constaté ce problème ?
Je n’ai pas trouvé d’issue qui en parle sur les différentes briques logicielles utilisées ; je suspecte que cela vienne du fork de Collabora que nous utilisons…
L’une des solutions potentiellement envisageables serait de mettre en place un cache sur les avatars du côté du reverse-proxy… en attendant, le rate limit fait le travail.
Il faudrait tester directement depuis le Collabora en question pour voir ce qui se passe, mais tu pourrais aussi modifier ton NextCloud pour désactiver les avatars dans Collabora pour voir si ça vient de Collabora ou pas.
L’adresse de l’avatar est transmise à Collabora par NextCloud dans le paramètre ExtraUserInfo.avatar :
Tu pourrais donc commenter cette ligne (et les suivantes qui spécifient avatar pour d’autres cas) pour désactiver les avatars dans Collabora, le temps de vérifier que le souci vient bien de Collabora et non de NextCloud lui-même.
Si ça vient de Collabora, essayer avec la version officielle et si confirmé, remonter le bug sur le github. Je peux appuyer ensuite avec notre contrat de support pour mettre la priorité sur ce bug.
L’URL appelée est assez curieuse, le paramètre c31f100db8b<hash> devrait correspondre à l’identifiant de la personne connectée, ou bien à défaut le nom de la personne invitée si non connectée, comme on le voit dans l’extrait partagé par @bohwaz au dessus, mais vraiment pas un hash. Le souci est donc soit Nextcloud qui génère mal les URL (voir dans core/Controller/AvatarController.php et core/Controller/GuestAvatarController.php), soit Collabora qui les récupère de manière erronée et fait des trucs bizarres avec (voir la gestion d’erreur autour de browser/src/core/LOUtil.js - setUserImage)
Les logs de Collabora peuvent aider à déterminer si c’est l’un ou l’autre, si jamais tu y as accès, selon la verbosité il me semble que le contenu de UserExtraInfo y est donné à la connexion.
Merci à vous deux pour vos précieux éclaircissements.
le paramètre c31f100db8b devrait correspondre à l’identifiant de la personne connectée, ou bien à défaut le nom de la personne invitée si non connectée,
Ah, en effet, c’est l’identifiant d’un·e utilisateur·ice. C’est un comportement attendu, car nous utilisons l’application user_oidc qui crée des comptes en leur donnant un hash comme identifiant (avec un displayname approprié).
Le plus embêtant, c’est que je n’arrive pas à reproduire ce bug… en édition collaborative, les avatars ne s’affichent pas (alors qu’ils devraient), mais mon navigateur ne s’entête pas à essayer de les retélécharger sans arrêt.
Pas de log étrange qui sort de l’ordinaire du côté de Collabora.
J’ai fini par me rendre compte que les avatars ne pouvaient pas être chargés en raison d’un problème de requête cross-origin…
La ressource à l’adresse « https://nextcloud.lacontrevoie.fr/avatar/neil/64 » a été bloquée en raison de son en-tête Cross-Origin-Resource-Policy (ou de son absence). Consultez https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)#
Pour l’instant, le problème semble résolu, les avatars sont bien chargés. Je miserais donc sur un bug de l’app richdocuments qui est a priori censée définir les headers, mais comme je n’arrive pas à reproduire le bug du chargement en boucle des avatars ni à joindre l’asso chez qui ça plante, j’ai du mal à débugger le problème en profondeur.
Hmm, des soucis avec ce genre de header (mais pas celui-ci spécifiquement) me font penser aux tickets suivants (les headers Cross-Origin-Opener-Policy et Cross-Origin-Embedder-Policy sont ajoutés partout pour le support de WASM dans Collabora - mais je ne crois pas que ça soit actif) :
À noter que Chrome & Firefox donnent souvent des messages d’erreurs assez différents pour un même problème.
Quoiqu’il en soit, tant mieux si c’est résolu dans ton cas, et merci pour le partage.
