Bien que l'explorateur de logs redirection.io soit rapide et offre de nombreuses options, il peut devenir fastidieux de répéter la même configuration de filtres pour obtenir un rapport spécifique. Par exemple, si votre routine hebdomadaire de surveillance de site web inclut la vérification des erreurs HTTP détectées par les moteurs de recherche, vous pourriez finir par en avoir un peu marre de configurer encore et encore les filtres "Code de statut" et "Type d'agent utilisateur".

Pour de tels cas, nous proposons la fonctionnalité "Vues des logs". Les vues des logs sont un moyen de sauvegarder une configuration spécifique de colonnes, de filtres et d'agrégation, et de pouvoir recharger cette configuration en un minimum de clics.

Nous avons déjà plusieurs "vues des logs" prédéfinies qui répondent à des cas d'utilisation d'analyse courants :

• Toutes les erreurs HTTP : Ce rapport affiche la liste de toutes les erreurs HTTP (à la fois 4xx et 5xx). Utilisez cette vue pour repérer les pics de problèmes pendant la dernière période de journalisation.
• Requêtes Googlebot vérifiées : Ce rapport liste toutes les requêtes qui ont été effectuées par Googlebot ou tout autre bot opéré par Google. Nous avons validé cette requête et filtré les bots tiers se faisant passer pour Googlebot.
• Erreurs Googlebot les plus courantes : Ce rapport affiche les erreurs HTTP les plus courantes rencontrées par Googlebot vérifié sur votre site web. Dans la mesure du possible, vous devriez essayer de résoudre ces problèmes en configurant une nouvelle règle de redirection.
• Faux Googlebot : Liste toutes les requêtes qui ont été envoyées en utilisant le User-Agent "Googlebot", mais que nous avons identifiées comme n'étant manifestement pas initiées par les services Google. Il se peut que ces requêtes soient effectuées par des bots tiers qui tentent de récupérer du contenu de votre site web.
• Erreurs HTTP les plus courantes : Ce rapport liste les 100 erreurs HTTP les plus courantes (4xx et 5xx), regroupées par URL et code de statut. Les erreurs sont triées par nombre d'occurrences.
• Pages les plus visitées : Affiche les URL les plus fréquemment visitées qui servent du contenu html.

Vous pouvez également définir vos propres vues de logs, qui seront sauvegardées au niveau du projet, afin que vous et vos collègues puissiez les utiliser.

Charger une "vue des logs" existante est une opération en un clic :

1. Passez la souris sur la petite roue dentée dans le coin supérieur droit de la barre de filtres
2. Ensuite, choisissez l'une des vues affichées, ou cliquez sur le bouton "Charger une autre vue".

📖 Vous pouvez lire la documentation complète sur les vues de logs dans la partie dédiée de notre documentation utilisateur.

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 !