Il y a quelques semaines, nous avons activé l'authentification à deux facteurs pour tous les comptes clients de redirection.io. Bien que cette fonctionnalité ait connu un certain succès, nous avons constaté qu'aider à améliorer la sécurité des comptes utilisateurs n'était pas suffisant. Certains clients de redirection.io ont des organisations avec des dizaines d'utilisateurs, et un seul compte ou mot de passe compromis pourrait entraîner la fuite de données sensibles de l'entreprise – statistiques de trafic, règles configurées, etc.

À partir d'aujourd'hui, nous offrons donc aux administrateurs d'organisation un moyen de renforcer l'accès aux projets de leur organisation, en rendant disponible un nouveau paramètre de sécurité. Les administrateurs d'organisation peuvent désormais exiger de tous les utilisateurs de l'organisation qu'ils activent l'authentification à deux facteurs sur leurs comptes personnels.

Une image vaut mille mots, alors voici à quoi cela ressemble :

Vous pouvez trouver des explications détaillées dans la documentation sur les Organisations.

Dans la version 1.6.0 de l'agent, nous avons introduit le mode test, une nouvelle façon de vous aider à tester et essayer vos règles de redirection avant qu'elles ne soient publiées sur vos serveurs de production. Historiquement, il n'était pas possible de logguer le trafic des instances configurées avec ce "mode test", qui était destiné aux serveurs de pré-production ou de test - nous estimions qu'il n'était pas très pertinent de logguer le trafic de ces plateformes.

Cependant, suite à plusieurs demandes sur ce sujet, nous avons modifié le comportement dans la récente version 2.1.0 de l'agent, et nous avons rendu possible l'activation du logging du trafic HTTP à partir des instances utilisant le "mode test". Désormais, vous pouvez obtenir une vue de vos journaux de trafic HTTP en direct même sur les instances de "test".

Une autre fonctionnalité très demandée concernant les instances était la possibilité de configurer leur comportement directement dans le fichier de configuration agent.yml. Nous avons introduit, également dans la version 2.1.0 de l'agent, les nouvelles configurations test_mode et logging, qui peuvent être utilisées pour définir statiquement la configuration des agents côté serveur. Si ces clés sont définies, vous ne pourrez plus modifier ce paramètre dans l'interface de gestion des instances :

Ce matin, nous avons lancé une manière améliorée de gérer les rôles au sein des organisations et des projets. En particulier, ces améliorations permettent la création d'utilisateurs "contributeurs" et "financiers", avec des permissions restreintes.

Les utilisateurs financiers peuvent accéder aux informations de facturation et aux factures - ce rôle est conçu pour répondre aux besoins des services financiers, qui n'ont généralement pas besoin d'accéder à toutes les fonctionnalités du projet.

Les utilisateurs contributeurs peuvent créer de nouvelles règles ou modifier celles existantes, mais ils ne peuvent pas publier de règles, ce qui signifie qu'ils n'ont pas d'accès direct aux règles de redirection exécutées sur votre site web public. Ceci est particulièrement utile pour permettre à une société de conseil SEO externe de contribuer de nouvelles règles de redirection pour votre site web, tout en ayant un moyen de contrôler en amont ce qui sera modifié sur votre site web.

Notre documentation sur les permissions a été mise à jour pour refléter ces changements.

Il y a quelque temps, nous avons été informés que plusieurs clients trouvaient difficile de comprendre le concept de "rang" des règles.

Le "rang" d'une règle est utile pour choisir la redirection à exécuter lorsque plusieurs règles correspondent à une requête donnée. Cependant, de nombreux utilisateurs hésitaient lors de la configuration du rang : le rang le plus bas était-il exécuté en premier ou après ? Plusieurs autres préoccupations concernant le "rang" ont été soulevées, entre autres le fait que le rang ne pouvait pas être inférieur à 0, interdisant ainsi d'insérer de nouvelles règles devant des règles de niveau 0 déjà existantes.

Par conséquent, nous avons renommé et migré le modèle de "rang" vers une propriété de "priorité", qui peut être attachée aux règles de redirection de vos projets comme le rang le faisait auparavant. L'ancien rang était en quelque sorte limité dans la plage 0-32768, nous l'avons donc transformé en une propriété de "priorité" qui peut varier de -32768 à 32767.

Désormais, si deux règles de redirection correspondent à une requête, celle qui a la priorité la plus élevée sera appliquée. Nous avons migré tous les plans de redirection existants, de sorte que vous ne remarquiez aucun problème avec les ensembles de règles existants.

Comme auparavant, vous pouvez modifier la priorité de chaque règle dans le formulaire de création/édition de règles. Vous pouvez également ajouter des exemples de requêtes à vos règles, et faire en sorte que les priorités relatives des règles soient automatiquement définies lors de l'ajustement de l'ordre des règles pour un exemple donné. Veuillez consulter notre guide sur la création de règles pour en savoir plus !