What's new on redirection.io?

Discover the latest news of our platform, improvements and important announcements.

Logs views, a faster way to explore your traffic logs

While the redirection.io logs explorer is snappy and offers many options, it can become annoying to repeat the same filters configuration to get a specific report. For example, if your weekly website monitoring routine includes checking the HTTP errors found by search engines, you could end up being a bit fed up with configuring again and again the "Status code" and "User agent type" filters.

For such cases, we offer the "Logs views" feature. Logs views are a way to save a specific columns, filters and aggregation configuration, and to be able to reload this configuration with as few clicks as possible.

An example logs view, which allows to easily filter traffic logs with redirection.io

We already several predefined "Logs views" that address common analysis use cases:

  • All HTTP errors: This report displays the list of all HTTP errors (both 4xx and 5xx). Use this view to spot issues peaks during the last logging period.
  • Googlebot verified requests: This report lists all the requests that have been performed by Googlebot or any other Google-operated bot. We have validated this request and filtered out third-party bots pretending to be Googlebot.
  • Googlebot most common errors: This report shows the most common HTTP errors encountered by verified Googlebot on your website. Whenever possible, you should try to solve these issues by setting up a new redirect rule.
  • Fake Googlebot: Lists all requests that have been sent using the "Googlebot" User-Agent, but that we identified as obviously not initiated by Google services. It may be that these requests are performed by third-party bots that try to scrape some content from your website.
  • Most common HTTP errors: This report lists the top 100 most common HTTP errors (both 4xx and 5xx), grouped by URL and status code. The errors are sorted by occurrence count.
  • Top hit pages: Displays the most frequently hit URLs that serve html content.

You can also define your own log views, that will be saved at the project level, so you and your colleagues can use them.

Loading an existing "logs view" is a one-click operation:

  1. The gear wheel opens the logs views menu Hover the small gear wheel on the top right corner of the filters bar
  2. The logs views submenu Then, choose one of the displayed views, or hit the "Load another view" button.

📖 You can read the full documentation about log views in the dedicated part of our user documentation.

Enforce Two-factor authentication in your organization

A few weeks ago, we have enabled two-factor authentication for all redirection.io customer accounts. While this feature has been fairly successful, we have found that helping to improve the security of user accounts was not enough. Some redirection.io customers have organization with dozens of users, and one single compromised account or password could result in the leakage of company sensitive data - traffic statistics, configured rules, etc.

So starting today, we're giving organization administrators a way to strengthen access to their organization's projects, by making a new security setting available. Organization administrators can now require all organization users to enable Two-factor authentication on their personal accounts.

A picture is worth a thousand words, so here is what it looks like:

The setting to require 2FA for all organization users

You can find detailed explanations in the documentation about Organizations.

Your test agent instances can now log

In the 1.6.0 release of the agent, we have introduced the test mode, a new way to help you test and try your redirect rules before they are published to your production servers. Historicaly, it was not possible to log the traffic from instances configured with this "test mode", which was meant for pre-production or testing servers - we estimated that it did not make much sense to log traffic from these platforms.

However, due to several requests on this topic, we have changed the behavior in the recent 2.1.0 release of the agent, and we have made it possible to enable HTTP traffic logging from instances using the "test mode". From now on, you can get a view of your live HTTP traffic logs even on "test" instances.

Web traffic logs live

Another much-demanded feature about instances was the ability to configure their behavior directly within the agent.yml configuration file. We have introduced, also in the 2.1.0 release of the agent, the new test_mode and logging configuration, which can be used to statically set the configuration of agents server-side. If those keys are defined, you will not be able anymore to change this setting in the instances management interface:

Instance details when the "logging" key is defined in the agent.yml config file

Better roles management

This morning, we have launched an improved way for managing roles within organizations and projects. In particular, these enhancements allow for the creation of "contributor" and "financial" users, with restricted permissions.

financial users can access billing information and invoices - this role is designed to fit the requirements of financial departments, which usually do not require access to all the project functionnality.

financial role attachment popin

contributor users can create new rules or modify existing ones, but they can not publish rules, which means that they do not have direct access to the redirection rules that are executed on your public website. This is especially useful to allow an external SEO consulting company to contribute new redirect rules for your website, while having a way to control upstream what is going to be changed on your website.

Our documentation about permissions has been updated to reflect these changes.

Goodbye, redirection rank. Welcome to rule priorities!

Some times ago, we have been made aware that several customers found it difficult to figure out the concept of rules "rank".

The "rank" of a rule is helpful to elect the redirection to execute when several rules match a given request. However, many users were hesitating when configuring the rank: was the lower rank executed first, or after? Several other concerns about the "rank" have been raised, among others the fact that the rank could not be lower than 0, thus forbidding to insert new rules infront of already existing 0-level rules.

Therefore, we have renamed and migrated the "rank" model to a "priority" property, that can be attached to the redirect rules of your projects just like the rank did before. The legacy rank was somehow limited in the range 0-32768, so we have transformed it into a "priority" property, that can range from -32768 to 32767.

Reorder rules from within an example

From now, if two redirection rules match a request, then the one with the higher priority will be applied. We have migrated all the existing redirection plans, so you do not notice any issue with existing rulesets.

As before, you can change the priority of each rule inside the rule creation/edition form. You can also add example requests to your rules, and have the relative priorities of rules be auto-defined when tweaking the rules order for a given example. Please read our guide about creating rules to learn more!

Reorder rules from within an example