1 points par GN⁺ 2023-08-11 | 2 commentaires | Partager sur WhatsApp
  • Microsoft Teams impose des limites opérationnelles très détaillées sur les équipes, canaux, chats, réunions et le partage de fichiers, et les noms de canaux ne peuvent pas utiliser des noms de périphériques MS-DOS comme CON, PRN, AUX, NUL, COM1~COM9 et LPT1~LPT9
  • Une équipe est limitée à 25 000 membres, un utilisateur peut appartenir à 1 000 équipes, et une équipe peut avoir 1 000 canaux ; les canaux supprimés continuent aussi de compter dans la limite pendant la période de restauration de 30 jours
  • Pour le chat, les seuils sont de 250 personnes en chat privé, 20 personnes pour les appels audio/vidéo lancés depuis un chat, 10 pièces jointes et 100 MB par fichier ; au-delà de 20 personnes, des fonctions comme les appels, l’indicateur de saisie et les accusés de lecture sont désactivées
  • Selon l’offre, les réunions peuvent accueillir jusqu’à 300 ou 1 000 participants, et les réunions, webinars et town halls Teams ont une limite de 30 heures ; les salles de répartition ne peuvent être créées que pour des réunions de moins de 300 personnes
  • Le partage de fichiers repose sur SharePoint et OneDrive for Business ; un tenant avec SharePoint désactivé subit donc des restrictions, et les fichiers Teams peuvent aller jusqu’à 25 TB par site ou groupe, avec un envoi limité à 250 GB par fichier

Limites des équipes et des canaux

  • Le nombre d’équipes qu’un utilisateur peut créer suit la limite de 250 objets de Microsoft Entra ID, à l’exception des administrateurs globaux
  • Un utilisateur peut être membre de 1 000 équipes maximum, y compris les équipes archivées
  • Les principales limites au niveau d’une équipe sont les suivantes
    • Membres : 25 000
    • Propriétaires : 100
    • Équipes à l’échelle de l’organisation : 5 par tenant
    • Membres d’une équipe à l’échelle de l’organisation : 10 000
    • Nombre d’équipes dans une organisation Microsoft 365 ou Office 365 : 500 000
    • Nombre d’équipes qu’un administrateur global peut créer : 500 000
  • Une équipe peut avoir jusqu’à 1 000 canaux, combinaison de canaux standard et partagés, avec au maximum 30 canaux privés
  • Les canaux supprimés peuvent être restaurés pendant 30 jours et continuent, pendant cette période, à être comptabilisés dans la limite de canaux par équipe ainsi que dans la limite de canaux privés
  • Les publications dans une conversation de canal sont limitées à environ 100 KB par publication, en incluant le corps, les liens d’image, les @mentions, le nombre de connecteurs et les réactions
    • Les images encodées en base64 ne sont pas comptées dans la limite des 100 KB

Contraintes des canaux partagés

  • Une équipe peut avoir jusqu’à 1 000 canaux partagés, les canaux supprimés restant comptabilisés pendant la période de récupération de 30 jours
  • Un canal partagé peut être partagé avec jusqu’à 50 équipes en plus de son équipe parente
  • Les membres d’un canal partagé peuvent aller jusqu’à 5 000 membres directs, et une équipe partagée compte pour 1 personne dans le calcul de la limite par équipe
    • Les mises à jour en temps réel ne sont fournies qu’à 25 000 personnes à la fois
    • La liste des canaux n’affiche que 25 000 personnes
  • Les participants externes ne prennent en charge que les comptes professionnels ou scolaires Microsoft Entra
  • Les canaux partagés prennent en charge les onglets, sauf Stream, Planner et Forms
  • Les bots, connecteurs et extensions de message ne sont pas pris en charge dans les canaux partagés
  • Les équipes à l’échelle de l’organisation ne peuvent pas être ajoutées comme membres d’un canal partagé
  • Lorsqu’une nouvelle équipe est créée à partir d’une équipe existante, les canaux partagés de l’équipe existante ne sont pas copiés
  • Les notifications de canaux partagés ne sont pas incluses dans les e-mails d’activité manquée
  • Les canaux partagés ne sont pas pris en charge dans les équipes de classe

Règles d’interdiction pour les noms de canaux

  • Les noms de canaux ne peuvent pas utiliser les caractères suivants
    • ~ # % & * { } + / \\ : < > ? | ' " , ..
  • Les plages de caractères suivantes ne peuvent pas non plus être utilisées
    • 0~1F
    • 80~9F
  • Les mots suivants ne peuvent pas être utilisés dans les noms de canaux
    • forms
    • CON, CONIN$, CONOUT$
    • PRN, AUX, NUL
    • COM1~COM9
    • LPT1~LPT9
    • desktop.ini
    • _vti_
  • Un nom de canal ne peut pas commencer par un underscore _ ou un point ., ni se terminer par un point .

Messagerie et chat

  • Les conversations figurant dans la liste de chat Teams sont stockées dans la boîte aux lettres Exchange Online des participants
  • Pour qu’un administrateur puisse rechercher ou conserver des conversations de chat, les participants doivent disposer d’une boîte aux lettres Exchange Online dans le cloud
    • Dans un déploiement Exchange hybride, les utilisateurs avec boîte aux lettres on-premises peuvent participer à un chat Teams
    • Dans ce cas, le contenu de la conversation ne peut pas être recherché ni conservé
  • Les principales limites du chat privé sont les suivantes
    • Nombre de personnes : 250
    • Nombre de membres pouvant être ajoutés à un chat de groupe en une fois : 200
    • Appels audio/vidéo lancés depuis un chat : 20
    • Pièces jointes : 10
    • Taille des fichiers : 100MB
    • Taille d’un message de chat : environ 100 KB
  • Lorsque le chat dépasse 20 personnes, les fonctions suivantes sont désactivées
    • Réponses automatiques Outlook et message de statut Teams
    • Indicateur de saisie
    • Appels audio/vidéo
    • Partage
    • Accusés de lecture
    • Bouton Set Delivery Options
  • Pour améliorer le taux de réussite de livraison des messages, il est recommandé de maintenir la taille du message lui-même à 80 KB ou moins
  • Les tenants avec abonnement d’évaluation peuvent faire l’objet de limites de messagerie plus strictes pour prévenir les abus, et ces limites peuvent être ajustées sans préavis
  • Les administrateurs qui n’autorisent que des domaines approuvés pour l’accès externe peuvent ajouter jusqu’à 4 000 domaines approuvés

E-mail de canal

  • Les e-mails envoyés à une adresse e-mail de canal deviennent partie intégrante du canal, et n’importe qui peut répondre pour démarrer une conversation
  • Les limites pour l’envoi d’e-mails à un canal sont les suivantes
    • Taille du message : 24 KB
    • Pièces jointes : 20
    • Taille par pièce jointe : moins de 10 MB
    • Images inline : 50
  • Au-delà de ces limites, le comportement change
    • Si le message dépasse 24 KB, un message de prévisualisation est créé et l’utilisateur doit télécharger l’e-mail original depuis le lien fourni pour le consulter
    • Si le nombre de pièces jointes ou d’images dépasse la limite, un message d’erreur s’affiche
  • Une limitation de débit s’applique aux e-mails de canal
    • 6 e-mails en 10 secondes par utilisateur et par canal
    • 8 e-mails en 10 secondes par utilisateur et par tenant
  • Les e-mails de canal ne sont pas disponibles dans Teams pour les organisations Office GCC/GCCH/DOD

Réunions et appels

  • Les offres Microsoft 365 Business Basic, Business Standard, Business Premium, Microsoft Teams Essentials et Microsoft 365 A1 permettent d’héberger des réunions en ligne et appels vidéo Teams jusqu’à 300 personnes
  • Dans les offres Microsoft 365 F1/F3/E3/E5/A3/A5/G3/G5, Office 365 E1/E3/E5/A3/A5/G1/G3/G5 et Microsoft Teams EEA, la limite monte à 1 000 personnes
  • Les principales limites liées aux réunions sont les suivantes
    • Appels audio/vidéo lancés depuis un chat : 20
    • Taille maximale d’un fichier PowerPoint : 2GB
    • Durée de disponibilité du téléchargement local d’un enregistrement de réunion non envoyé vers Microsoft Stream : 20 jours
    • Durée maximale d’un enregistrement de réunion : 4 heures ou 1.5GB
  • Lorsqu’un enregistrement atteint la durée ou la taille maximale, l’enregistrement s’arrête et redémarre automatiquement
  • Les salles de répartition ne peuvent être créées que pour des réunions avec moins de 300 participants
    • La création de salles de répartition limite automatiquement le nombre de participants à 300
  • Les réunions, webinars et town halls Teams ont une limite de temps de 30 heures

Expiration des réunions

  • L’expiration des réunions s’applique aux numéros d’appel PSTN, aux coordonnées CVI, ainsi qu’aux politiques et paramètres de réunion par défaut
  • Si quelqu’un rejoint la réunion ou si la réunion est mise à jour avant expiration, 60 jours sont ajoutés à la limite d’expiration, sauf pour les réunions Meet now
  • Selon la préversion publique, les nouveaux liens et réunions expirent selon les conditions suivantes, et il n’est plus possible de rejoindre via le lien après expiration
    • Réunion ponctuelle planifiée : 60 jours après l’heure de réunion prévue
    • Meet now planifié depuis le calendrier ou un canal : 60 jours après la création du lien
    • Meet now planifié dans un chat de groupe : non applicable
    • Réunion récurrente avec date de fin : 60 jours après la date de fin ou 60 jours après la dernière occurrence, selon la durée la plus longue
    • Réunion récurrente sans date de fin : 1 an après le dernier accès, la dernière participation ou la dernière mise à jour de la réunion

Événements en direct

  • Les événements en direct Teams doivent prendre fin en juillet 2026
    • Les événements déjà planifiés seront pris en charge jusqu’au 28 février 2027
    • Microsoft recommande d’utiliser Teams town hall pour les grands événements numériques et hybrides
  • Les limites par défaut des événements en direct sont les suivantes
    • Participants : jusqu’à 10 000
    • Durée de l’événement : 4 heures
    • Nombre d’événements en direct pouvant être exécutés simultanément dans une organisation Microsoft 365 ou Office 365 : 15
  • Dès qu’un producteur rejoint un événement en direct, celui-ci est considéré comme en cours d’exécution
    • Le producteur qui tente de rejoindre un 16e événement en direct reçoit une erreur
  • L’augmentation temporaire des limites est prolongée jusqu’à nouvel avis
    • Jusqu’à 20 000 participants
    • 50 événements simultanés à l’échelle du tenant
    • 16 heures par diffusion
  • Via le Microsoft 365 assistance program, il est possible de planifier des événements en direct allant jusqu’à 100 000 participants, l’équipe évaluant chaque demande pour déterminer les options possibles

Stockage et partage de fichiers

  • Chaque équipe Teams dispose d’un site d’équipe SharePoint, et chaque canal crée un dossier dans la bibliothèque de documents du site d’équipe par défaut
  • Les fichiers partagés dans les conversations sont automatiquement ajoutés à la bibliothèque de documents, et les autorisations ainsi que les options de sécurité des fichiers définies dans SharePoint sont répercutées dans Teams
  • Chaque canal privé dispose d’un site SharePoint distinct
  • Si SharePoint n’est pas activé dans le tenant, les utilisateurs Teams ne peuvent pas toujours partager des fichiers dans les équipes
  • Le partage de fichiers dans un chat privé nécessite OneDrive for Business associé à une licence SharePoint
  • Comme le partage de fichiers Teams fonctionne sur l’infrastructure SharePoint, les limitations SharePoint s’appliquent à la section Files de Teams
  • Les limites de stockage des offres affichées sont les suivantes
    • 1TB par organisation + 10GB par licence achetée
    • Office 365 Enterprise F1 : 1TB par organisation
    • Teams Files : jusqu’à 25TB par site ou groupe
    • Limite d’envoi : 250GB par fichier
  • Comme les canaux reposent sur des dossiers dans le site SharePoint de l’équipe, l’onglet fichiers d’un canal partage la limite de stockage de l’équipe à laquelle il appartient

Équipes de classe et tags pour l’éducation

  • Microsoft Teams for Education propose des modèles pour les scénarios éducatifs, comme les cours en classe
  • L’utilisation d’une équipe de classe nécessite une licence Office 365 Education
  • Les équipes de classe suivent la limite générale de membres des équipes, mais certaines applications ont des restrictions distinctes
    • Utilisation de l’application Assignments : 1 000 membres
    • Utilisation de l’application OneNote Class Notebook : 300 membres
  • Les équipes de classe peuvent prendre en charge davantage de membres, mais si vous prévoyez d’utiliser Assignments ou Class Notebook, il faut rester sous les limites ci-dessus
  • Les limites des tags sont les suivantes
    • Tags par équipe : 200
    • Tags par défaut suggérés par équipe : 25
    • Membres d’équipe pouvant être attribués à un tag : 200
    • Tags attribuables à un utilisateur dans une équipe : 25

Contacts et prise en charge des navigateurs

  • Teams utilise les contacts Active Directory de l’organisation ainsi que les contacts ajoutés par l’utilisateur au dossier par défaut d’Outlook
  • Les utilisateurs Teams peuvent communiquer avec toute personne présente dans l’Active Directory de l’organisation et l’ajouter à leur liste de contacts depuis Chat > Contacts ou Calls > Contacts
  • Il est aussi possible d’ajouter comme contact, depuis Calls > Contacts, des personnes qui ne figurent pas dans l’Active Directory de l’organisation
  • La présence Teams dans Outlook est prise en charge à partir de l’application de bureau Outlook 2013
  • La prise en charge des navigateurs varie selon les fonctionnalités
    • Internet Explorer 11 ne prend pas en charge les appels et ne prend en charge que de manière limitée les réunions avec coordonnées PSTN
    • Les versions récentes de Microsoft Edge Chromium et Google Chrome prennent entièrement en charge les appels et les réunions
    • Firefox ne prend pas en charge les appels mais prend en charge les réunions, avec nécessité du plugin OpenH264 pour la prise en charge complète
    • Selon la version de Safari, la prise en charge des appels 1:1, de la vidéo et du partage varie
  • Dans le navigateur, les réunions Teams sont limitées à un seul flux, avec affichage soit de la vidéo entrante de l’intervenant actuel, soit du partage d’écran
  • Pour céder ou reprendre le contrôle pendant un partage, les deux côtés doivent utiliser le client de bureau Teams ; ce n’est pas pris en charge dans le navigateur

2 commentaires

 
xguru 2023-08-11

Je suppose que c’est dû à la rétrocompatibilité avec Windows.

Mais je me demande si les développeurs d’aujourd’hui connaissent encore des trucs comme COM, LPT ou PRN, haha.

On voit aussi parfois des questions du genre : « Pourquoi les disques durs commencent-ils à C ? »

 
GN⁺ 2023-08-11
Avis sur Hacker News
  • Vers 1998, ado et fanatique de Linux, j’emmenais ma machine Linux aux LAN parties, et en pratique ça marchait très bien.
    À l’époque, WINE existait presque surtout pour prendre en charge Starcraft, Quake 2 tournait en natif, et à eux deux ils couvraient 95 % des jeux auxquels les gens jouaient.
    Une fois, j’ai trouvé drôle de lancer un script shell qui parcourait tous les partages Windows du réseau pour ouvrir CON/CON, et chaque machine a immédiatement affiché un écran bleu ; bizarrement, mes amis n’ont pas trouvé ça amusant.

    • Ça me rappelle cette époque. À chaque LAN, il y avait toujours un pote comme ça.
      S’il était doué pour résoudre les problèmes réseau et apportait toujours des câbles CAT-5 de rechange, comme mon pote sous BSD, ça aurait largement compensé.
    • C’était fait avec IPX ? Je ne me souviens pas avoir configuré IPX sous Linux.
      Il me semble qu’à l’époque où j’utilisais Linux au point de faire tourner Starcraft avec Wine, il prenait déjà en charge IP.
    • J’adore cette histoire. Je ne savais pas que WINE existait depuis si longtemps et pouvait déjà faire tourner des jeux comme Starcraft.
      J’ai de très bons souvenirs de parties de Starcraft avec des amis, et ce jeu a eu une longévité telle que j’ai pu y être accro au collège, puis de nouveau à l’université.
    • Le meilleur, c’était le piratage à la portée de tous : lancer un ping flood sur les gens pendant les LAN parties.
      Bons vieux souvenirs.
    • C’était l’âge d’or. Je ne sais pas si c’est nous qui étions différents, ou si le monde autour de nous l’était.
  • C’est probablement parce que le système de fichiers Windows n’autorise pas ces noms pour des fichiers ou des dossiers.
    Un canal MS Teams crée un dossier correspondant dans SharePoint, où sont stockées les pièces jointes.

    • Microsoft semble se dire, face à un problème : « D’accord, construisons ça au-dessus de SharePoint ».
    • J’ai travaillé dans une banque qui utilisait un système de trading basé sur Windows ; pour une raison quelconque, il créait des dossiers contenant les détails de chaque book.
      Les ennuis ont commencé quand un trader a nommé son book LPT1.
    • Il doit aussi y avoir d’autres vulnérabilités là-dedans. Cela dit, ils semblent aussi mettre % et .. sur liste noire.
    • Un groupe Active Directory correspondant est également créé.
      C’est un moyen très simple de permettre aux utilisateurs de gérer les droits d’accès aux ressources sans ouvrir de ticket de support, donc l’usage en est plutôt correct.
    • SharePoint a profondément planté ses griffes dans Microsoft, et restera à jamais leur talon d’Achille.
  • Au début, j’allais dire : « N’est-ce pas quasiment révéler qu’il y a quelque chose d’horrible en interne ? Ils devraient avoir honte de dire ça publiquement. C’est un peu comme dire qu’on ne peut pas utiliser %s ou $PS1 : pourquoi donc ? Qu’est-ce qu’ils font avec les entrées utilisateur ? »
    Mais il peut aussi s’agir de la manière dont le nom du canal sera traité ailleurs. Les gens peuvent le copier-coller n’importe où, et je ne pense pas qu’on s’attende à ce que les utilisateurs Windows échappent eux-mêmes leurs chaînes lorsqu’ils les collent dans cmd, PowerShell ou WSL.
    Le code de Teams lui-même sait probablement gérer ça correctement, mais le problème peut venir de toutes sortes d’outils externes inconnus et bancals capables de manipuler les noms de canaux.
    D’autres ont pointé le dossier SharePoint associé au canal ; or il est facile d’échapper, transformer ou encoder le nom pour produire une version sûre pour les répertoires, donc j’ai du mal à leur accorder des circonstances atténuantes. Cela dit, il peut être important, quelque part, que le nom du canal et celui du répertoire soient identiques.
    Si c’est uniquement utilisé dans l’application, il suffit d’encoder/décoder le nom du canal et celui du répertoire de la même manière et de le cacher complètement à l’utilisateur ; mais si le répertoire est aussi utilisé hors de l’application, une forme comme l’encodage d’URL s’affiche telle quelle et devient laide.
    Au final, le nom du répertoire doit être sûr pour tout le reste, donc le nom du canal doit l’être aussi. Ils ont donc choisi cette restriction plutôt que d’avoir parfois des noms de répertoires moches, et au bout du compte c’est davantage un problème d’apparence que de sécurité ou de panne. Comme les caractères qui auraient nécessité un encodage ne sont tout simplement pas autorisés, tous les répertoires ont toujours un aspect naturel et propre.

    • Si vous avez l’occasion de voir un flux brut de réponses DNS NXDOMAIN issues d’un DNS passif (PDNS), il y a énormément de choses cassées, et certaines sont franchement inquiétantes.
      Ce genre de choses arrive quand on convertit des services de noms entre eux. Les services de noms ont généralement un périmètre d’application, et un nom dans un contexte est interprété différemment dans un autre.
      Bobby Tables est bien connu, mais qu’en est-il du nom de fichier spécial -rf ? À une époque, le chemin normal d’Active Directory faisait presque implicitement confiance aux noms de domaine DNS dans des endroits comme les partages de fichiers. Ça paraît acceptable jusqu’à ce qu’on réalise qu’il peut y avoir un exécutable sur ce « lecteur ».
      Honnêtement, je n’ai pas trouvé la chaîne MS-DOS dans ce document. Correction : j’ai trouvé des références comme CON et LPT1.
    • C’est simplement une limitation des noms de dossiers SharePoint qui remonte à la surface. Rien de spécial.
    • « On ne s’attend pas à ce que les utilisateurs échappent eux-mêmes leurs chaînes » : les utilisateurs de quel système ont déjà commencé à répondre à une telle attente ? Il est où, ce système utopique ?
    • AWS impose des restrictions de caractères sur pratiquement tout.
      Même le corps des messages SQS a des limites sur les caractères d’espacement autorisés.
    • C’est une limitation de SharePoint. Teams repose sur SharePoint, ce n’est ni un secret ni quelque chose de honteux.
  • Pourquoi la plupart des apps de chat/réunion finissent-elles par devenir horribles ? Je me souviens d’une époque où Teams était une appli correcte. Il y avait même un client desktop Linux
    Je me souviens aussi d’une époque où Slack était vraiment rapide, et où Skype Out était plus fiable que mes appels sur mobile
    Aujourd’hui, Slack devient extrêmement lent dès qu’on ajoute seulement quelques organisations. Au moins, on peut en ajouter plus d’une
    Teams a abandonné son client desktop Linux, et pour l’utiliser sous Linux il faut passer par Chrome. Mais quand on l’utilise comme partie d’Office 365/SharePoint, « certains » liens SharePoint nécessitent Firefox
    Au final, il faut toujours deux navigateurs. Chrome pour le partage d’écran et la vidéo dans Teams, Firefox pour certains liens SharePoint

    • Aussi difficile à croire que cela puisse paraître, les apps de chat/réunion sont la porte d’entrée la plus simple vers l’app à tout faire, comme WeChat
      En fin de compte, une app de chat/réunion est une miniature d’Internet
      Une app de chat, c’est très bien, mais pourquoi ne pas pouvoir aussi envoyer et partager des clips audio, puis des clips vidéo, de la vidéo en direct, de l’argent, des réunions, des invitations de calendrier, des demandes de livraison de repas, des sessions de jeu, X, etc.
      Il n’y a pas de limite à X. Internet consiste à partager X, et une app de chat consiste aussi à partager X ; il n’y a donc en pratique aucune frontière à la taille que cela peut prendre
    • L’essentiel, c’est de faire quelque chose de horrible et simple dès le départ. IRC fonctionne toujours aussi médiocrement qu’il y a 30 ans
    • Une partie du problème semble venir de la pression qui pousse à ajouter sans cesse des fonctionnalités
      Le chat et la vidéo fonctionnent, mais pourquoi ne pas ajouter le floutage d’arrière-plan ? Merde, Zoom a des sondages, donc il nous faut aussi des sondages. Si on veut sortir des fonctionnalités à la chaîne et itérer vite, autant utiliser Electron, et ainsi de suite
    • Le marché récompense les fonctionnalités et les intégrations, pas la performance, tant que l’app reste utilisable. Les développeurs développent… enfin, des fonctionnalités, des fonctionnalités, des fonctionnalités
    • Une équipe de startup agile et productive crée une app que tout le monde aime, puis lève beaucoup d’argent et finit par embaucher des milliers de développeurs logiciel superflus
      Et ensuite, il faut bien leur trouver quelque chose à faire
  • J’adore ça. J’aime le fait que ce nouveau truc rappelle les tout débuts de MS-DOS, au tout début des années 90, quand il tournait sur des 086 ou des 286
    Il faut respecter l’obsession de Microsoft pour la rétrocompatibilité. C’est comme imaginer, de façon impossible, qu’un port natif de MS Teams soit en préparation pour MS-DOS 3.1. Plus plausible encore, on pourrait imaginer que le serveur MS Teams tourne sur un antique et bizarre mainframe propriétaire sous MS-DOS 3.1, mais ça n’a évidemment pas beaucoup plus de sens
    Je savais que cette restriction sur les noms de périphériques s’appliquait aussi aux noms de fichiers Windows, donc si l’on a un tempérament peu porté sur l’amusement, ce n’est pas si surprenant. Mais si on aime s’amuser, on peut se laisser aller aux imaginations précédentes
    Lien associé : https://learn.microsoft.com/en-us/microsoftteams/limits-spec...

    • « MS-DOS tournant sur des 086 ou des 286 au tout début des années 90 », c’est décalé d’environ 10 ans
      MS-DOS tournait sur 8086 au début des années 80
    • C’est quand même surprenant. Avec WSL, on peut créer de tels fichiers, mais sous Windows on ne peut ni les créer ni les supprimer, ce qui n’a aucun sens
      Windows 10 ou 11 n’ont plus de couche DOS, et c’est plutôt que Microsoft n’a pas l’intention de corriger ce genre de problème
    • La rétrocompatibilité est un objectif louable et j’apprécie les efforts en ce sens
      J’aimerais simplement que cela n’aille pas jusqu’à limiter les mots de passe à une longueur ridiculement courte ou à un jeu de caractères absurdement restreint
  • Ça me rappelle la rumeur selon laquelle la raison pour laquelle on est passé de « Windows 7 », « 8 » directement à « 10 » en sautant « 9 », c’est qu’on craignait qu’il existe quelque part dans la base de code un truc du genre
    if(version.StartsWith(“Windows 9”)) { /* 95 and 98 */ ... }

    • Une version de Windows a-t-elle déjà été exposée sous forme de chaîne via l’API Windows ?
      Je n’ai pas d’expérience Windows, mais ça me paraît un peu étrange. D’un côté, c’est le genre de chose que Microsoft pourrait faire pour préserver la rétrocompatibilité ; de l’autre, ça ressemble à une API bizarre à fournir
      J’ai trouvé GetVersion[1], mais elle renvoie la version sous forme de deux nombres
      [1] https://learn.microsoft.com/en-us/windows/win32/api/sysinfoa...
  • Mots interdits : forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, de COM1 à COM9, de LPT1 à LPT9, desktop.ini, _vti_

    • Au début, j’allais dire : « En pratique, ça ne revient-il pas à révéler qu’il y a quelque chose d’horrible en interne ? Ils devraient avoir honte de dire ça publiquement. C’est un peu comme dire qu’on ne peut pas utiliser %s ou $PS1 ; pourquoi pas ? Qu’est-ce qu’ils font exactement avec les entrées utilisateur ? »
      Mais il peut aussi s’agir de la manière dont les noms de canaux sont traités ailleurs. Les gens peuvent les copier-coller n’importe où, et apparemment on ne s’attend pas à ce que les utilisateurs Windows échappent eux-mêmes leurs chaînes quand ils les collent dans cmd, PowerShell ou WSL
    • Au milieu des années 90, il y a eu une courte période amusante où des clients IRC comme mIRC pouvaient être configurés pour recevoir automatiquement des fichiers via DCC
      Et ils écrivaient volontiers vers des noms comme LPT1, auquel cas, bien sûr, les données partaient directement vers l’imprimante du destinataire
    • Je me demande s’il a réellement existé des machines avec un LPT9. COM9, j’arrive tout juste à l’imaginer
  • Un conseil général quand on structure des données utilisateur est de les traiter, autant que possible, comme un bloc opaque.
    Imaginez qu’elles soient chiffrées et qu’il soit impossible de les afficher ou de les lire par un humain.
    forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1 à COM9, LPT1 à LPT9, desktop.ini, _vti_
    Si vous devez interdire ce genre de choses parce que la saisie utilisateur arrive telle quelle dans le système de fichiers, c’est que vous avez raté quelque chose. Il aurait fallu attribuer un ID sûr au lieu d’utiliser directement la saisie utilisateur. Ça pourrait être un uuid4, ou bien un condensat du nom du canal.
    Quand quelqu’un dit « ce caractère ne peut pas être utilisé », ça sent mauvais. Je pense automatiquement : « Pourquoi pas ? Vous n’êtes quand même pas en train de l’utiliser en clair, sans l’encoder ? » Des contenus affichés sur une page web, comme les mots de passe, les noms d’utilisateur ou les commentaires, en sont des exemples.
    Cela dit, tout cela pourrait aussi être un mauvais easter egg. Ils ont peut-être juste voulu ajouter un peu de fun et ça a mal tourné.

  • C’est mauvais, certes, mais honnêtement, quel est l’objectif ? Permettre aux gens de donner absolument n’importe quel nom, y compris aux canaux ? Par exemple un nom comme "rm -rf /*".
    Il y a encore mieux : écrire ce rm -rf avec le caractère de redéfinition directionnelle RLO pour qu’il ressemble à fr- mr.
    Faut-il vraiment viser cela ? En croyant qu’aucun problème ne surviendra ?
    Heureusement, sous Linux, on ne peut pas créer un fichier nommé https://example.org. Windows aussi, non ?
    Plus sérieusement, est-ce vraiment un problème ? Et si oui, où faut-il tracer la ligne ?
    Le point de code 0 ? Le caractère de remplissage hangul et le caractère RLO ? Considérez-vous qu’une application qui les refuse est médiocre ?
    Heureusement, ce qui peut entrer dans un nom de fichier est soumis à des limites. Et je pense que les limites actuelles ne sont même pas assez strictes. Il en va de même pour les noms d’utilisateur, les canaux et énormément d’autres choses.
    Par exemple, est-ce que quelqu’un considère vraiment comme un problème le fait que Twitter n’autorise que les caractères alphanumériques visibles et le tiret bas, avec une limite de 15 caractères ?
    Ça me paraît être une approche très intelligente. Bien meilleure que de rêver de pouvoir mettre un emoji caca dans les noms d’utilisateur et de canal.

    • On ne peut pas créer un fichier nommé https://example.org, mais on peut tout à fait créer un chemin comme celui-là.
      Les doubles barres obliques internes sont ignorées, et il suffit de créer un répertoire nommé https: et un fichier nommé example.org.
    • Pour effacer des données, je pense que dd convient mieux que rf.
  • Si le titre du canal est utilisé comme dossier SharePoint, il est surprenant qu’il n’existe pas de méthode d’échappement standard pour ce genre de chaînes.
    Cela casserait la compatibilité avec les applications qui dépendent de ces fichiers de périphérique magiques, mais SharePoint ne devrait absolument jamais avoir besoin de communiquer réellement avec COM1.
    Il est étrange que SharePoint ne gère pas déjà cela.

    • SharePoint peut se synchroniser avec le système de fichiers Windows, et Windows/Win32 ne prend pas en charge ces noms pour des raisons de rétrocompatibilité.