Весьма странная ошибка captcha rust

Одним из факторов, влияющих на надёжность программного обеспечения, является способ обрабатывать ошибки, возникающие в процессе выполнения. Создатели Rust не стали повторять популярные методы, а выбрали другой способ, позволяющий описывать и обрабатывать ошибки более явно. В статье мы рассмотрим реализацию данного подхода, а также полезные библиотеки, упрощающие обработку ошибок.

Содержание

1. Что делать с ошибкой?

2. Немного о синтаксисе Rust

3. Обработка ошибок в Rust

4. Полезные библиотеки

5. Заключение

Что делать с ошибкой?

Для начала, порассуждаем о возможных вариантах действий при возникновении ошибки в ходе выполнения программы. Вариантов у нас, в конечном счёте, всего три:

1. Завершить работу программы. Это самый простой вариант, не требующий больших усилий от разработчика. Он применим в случаях, когда ошибка не позволяет программе корректно выполнять свои функции. В качестве примера можно рассмотреть приложение, представляющее собой обёртку над некоторой динамической библиотекой. Скажем, графический интерфейс. Приложение поставляется с этой библиотекой и не несёт какой-либо пользы в отрыве от неё. Разумно предположить, что приложение не должно работать без этой библиотеки. Поэтому, вполне обосновано, при ошибке загрузки библиотеки, прерывать работу приложения.

2. Обработать ошибку. Чтобы программа могла продолжить выполнение после возникновения ошибки, требуется отреагировать на эту ошибку так, чтобы корректная часть программы могла далее выполнять свои функции, потеряв, возможно, доступ к некоторым возможностям. Рассмотрим приложение, использующее модули в виде динамических библиотек. В данном случае, отсутствие библиотеки модуля, необходимого для выполнения выбранного пользователем действия — это повод отменить выполнение действия, а не прерывать программу. Как вариант, сообщим пользователю об отсутствии требуемого модуля и предложим другие варианты работы.

3. Пропустить ошибку на более высокий уровень. Далеко не всегда, в момент получения ошибки, есть возможность однозначно выбрать способ её обработки. В таких случаях можно передать ответственность по обработке ошибки выше по иерархии вызовов. Например, подсистема загрузки конфигурационных файлов может использоваться сразу в нескольких других системах приложения. Поэтому не разумно обрабатывать случай отсутствия запрошенного файла внутри неё, одинаково для всех обратившихся. Более подходящий вариант — предоставить каждой клиентской системе самой решать, как действовать в случае ошибки загрузки конфигурации.

Ошибки, после которых приложение должно завершить работу называют неустранимыми. Остальные — устранимыми. Тип конкретной ошибки не зависит от самой ошибки (некорректный ввод, файл не найден, …). Он зависит от решения разработчика: стоит ли продолжать работу программы при этой ошибке, или программа больше ничего не может сделать. Нужно искать компромисс, исходя из требований к надёжности системы и имеющимися ресурсами для разработки, так как восстановление после ошибки требует от разработчика некоторых усилий. В лучшем случае, достаточно просто сообщить о ней пользователю и продолжить работу. Но бывают ситуации, когда для восстановления от ошибки требуется создать целую резервную систему.

Механизм обработки ошибок в Rust требует явно указывать, как вы классифицируете каждую ошибку. Для того чтобы разобраться, как этот механизм устроен, давайте рассмотрим некоторые особенности синтаксиса Rust, которые в нём применяются.

Немного о синтаксисе Rust

Механизм обработки ошибок включает себя две особенности языка Rust: перечисления с данными и трейты.

Трейты

Трейты схожи с концепцией интерфейсов в других языках. Их можно реализовывать на типах, расширяя их функционал. Также, функции могут накладывать ограничение на трейты принимаемых аргументов. Ограничения проверяются при компиляции. Например:

fn main() {
    let int_value: i32 = 42;
    let float_value: f32 = 42.0;

    print_value(int_value);
    // Строка ниже ломает компиляцию, так как для float не реализован трейт Print
    // print_value(float_value);
}

trait Print {
    fn print(&self);
}

impl Print for i32 {
    fn print(&self) {
        println!("Printing i32: {}", self)
    }
}

fn print_value<T: Print>(value: T) {
    value.print()
}

Ссылка на Playground

В данном примере мы определили трейт Print и реализовали его для встроенного целочисленного типа i32. Также, мы определили функцию print_value(), принимающую обобщённый (generic) аргумент value, ограничив варианты его типа только теми, которые реализуют трейт Print. Поэтому в main() мы можем вызвать print_value() только с i32 аргументом.

Более того, при определённых условиях, можно создавать трейт объекты (trait objects). Это динамический объекты, которые могут быть созданы из любого типа, реализующего данный трейт. Конкретная реализация метода трейта выбирается динамически (dynamic dispatch). Например:

trait Animal {
    fn says(&self);
}

struct Cat {}
struct Dog {}

impl Animal for Cat {
    fn says(&self) {
        println!("Meow")
    }
}

impl Animal for Dog {
    fn says(&self) {
        println!("Woof")
    }
}

fn main() {
    let cat = Cat{};
    let dog = Dog{};
    
    say_something(&cat);
    say_something(&dog);
}

fn say_something(animal: &dyn Animal) {
    animal.says()
}

Ссылка на Playground

В данном коде нет необходимости делать функцию say_something() обобщённой, так как конкретная реализация, скрытая за трейт объектом разрешается во время выполнения программы, а не при компиляции.

Также, стоит упомянуть о том, что трейты могут наследоваться. То что трейт Mammal унаследован от трейта Animal означает, что реализовать трейт Mammal может только тип, реализующий Animal.

trait Animal {}

trait Mammal: Animal {}

struct Cat {}
struct Dog {}

impl Animal for Cat {}
impl Mammal for Cat {}

impl Mammal for Dog {}

Ссылка на Playground

Данный код не компилируется, так как мы пытаемся реализовать трейт Mammal на типе Dog, не реализовав Animal, от которого Mammal унаследован.

Перечисления с данными

Данный элемент синтаксиса позволяет привязать данные разных типов к разным вариантам перечисления. Например, вы можете принимать в качестве аргумента IP адрес, не уточняя версию:

enum IpAddr {
    IPv4(u32),
    IPv6(String),
}

fn connect(addr: IpAddr) {
    match addr {
        IpAddr::IPv4(integer_address) => {...}
        IpAddr::IPv6(string_address) => {...}
    }
}

Ключевое слово match позволяет описать действия для различных вариантов перечисления и их содержимого.

Перечисления могут быть обобщенными:

struct DateFormatA {}
struct DateFormatB {}

enum Date<DateFormat> {
    InFormat(DateFormat),
    AsOffset(u32)
}

fn in_format_a() -> Date<DateFormatA> {
    Date::InFormat(DateFormatA {})
}

fn in_format_b() -> Date<DateFormatB> {
    Date::AsOffset(42)
}

fn main() {
    let _a = in_format_a();
    let _b = in_format_b();
}

Ссылка на Playground

Разобравшись с типажами и перечислениями, можно переходить к механизму обработки ошибок.

Обработка ошибок в Rust

В Rust есть два перечисления на которых строится, практически, вся обработка ошибок: Option и Result. Рассмотрим их подробнее.

Option

Определение:

pub enum Option<T> {
    None,
    Some(T),
}

Семантика его проста: либо мы имеем некоторые данные, либо они отсутствуют. Таким образом, возвращая из функции Option мы, тем самым, выражаем мысль, что, возможно, мы не получим ожидаемый результат.

Result

Определение:

pub enum Result<T, E> {
    Ok(T),
    Err(E),
}

В отличие от Option, Result позволяет установить не только отсутствие данных, но и причину, в связи с которой они отсутствуют.

Рассмотрим теперь, как в Rust выразить три действия при ошибке, которые мы перечислили в начале статьи:

• Завершить работу приложения.

• Обработать ошибку.

• Пропустить ошибку на более высокий уровень.

Завершаем работу приложения

Rust требует от разработчика явно демонстрировать своё намерение прервать программу в случае ошибки. Аварийное завершение работы программы в Rust называется паникой. Вызвать её можно с помощью макроса panic!(), позволяющего указать сообщения об ошибке для вывода.

fn main() {
    let broken = true;
    
    if broken {
        panic!("Program is broken!")
    }
}

Ссылка на Playground

Так как для обработки ошибок, обычно, используются Option и Result, для завершения работы программы нужно писать что-то вроде:

match opt {
    Some(value) => value,
    None => panic!("No value in option!")
};

match res {
    Ok(value) => value,
    Err(error) => panic!("Error happaned: {}!", error)
};

Для удобства, Option и Result содержат ассоциированную функцию unwrap(), позволяющую не повторять приведённый выше код. Если перечисление находится в состоянии успеха, то unwrap() достаёт данные из перечисления и позволяет с ними работать. В случае ошибки, unwrap() вызывает панику. У unwrap() есть аналог, позволяющий добавить произвольный текст к выводу: expect().

fn main() {
    let settings = read_settings().unwrap();
    let _service = create_service(settings).expect("Can't create service");
}

fn read_settings() -> Option<String> {
    // Some settings loading code
    None // Settings is not found
}

struct Service {}

#[derive(Debug)] // Generate implementation for Debug trait, required by .expect()
enum CreateServiceError {
    BadSettings,
    InternalError,
}

fn create_service(_settings: String) -> Result<String, CreateServiceError> {
    // Some service creation code
    let bad_settings = true;
    if bad_settings {
        Err(CreateServiceError::BadSettings)
    } else {
        Err(CreateServiceError::InternalError)
    }
} 

Ссылка на Playground

Обрабатываем ошибку

Вызывая функцию, которая может не сработать, мы получаем в качестве результата Option или Result. Если нам известно, что делать в случае неудачи, мы должны выразить свои намерения через конструкции языка. Рассмотрим пример:

fn main() {
    let some_settings = String::from("some settings");

    let s1 = match load_settings() {
        Some(s) => s,
        None => some_settings.clone(),
    };

    let s2 = load_settings().unwrap_or_default();

    let s3 = load_settings().unwrap_or(some_settings);
    
    let s4 = load_settings().unwrap_or_else(|| {String::from("new string")});
    
    println!("s1: {}", s1);
    println!("s2: {}", s2);
    println!("s3: {}", s3);
    println!("s4: {}", s4);
}

fn load_settings() -> Option<String> {
    None
}

Ссылка на Playground

В данном примере мы используем разные способы замены строки настроек, в случае неудачи при её получении:

• s1 — явно сопоставляем Option с шаблоном и указываем альтернативу.

• s2 — используем функцию unwrap_or_default(), которая в случае отсутствия данных возвращает значение по умолчанию (пустую строку).

• s3 — используем unwrap_or(), возвращающую свой аргумент в случае отсутствия данных.

• s4 — используем unwrap_or_else(), возвращающую результат вызова переданного в неё функтора в случае отсутствия данных. Такой подход позволяет вычислять значение резервного варианта не заранее, а только в случае пустого Option.

Перечисление Result предоставляет аналогичные методы.

Пропускаем ошибку выше

Для начала, сделаем это вручную. Для Option:

fn main() {
    let module = init_module().unwrap();
}

struct Module {
    settings: String,
    dll: Dll,
}

struct Dll {}

fn init_module() -> Option<Module> {
    let settings = match load_settings() {
        Some(s) => s,
        None => return None,
    };

    let dll = match load_dll() {
        Some(dll) => dll,
        None => return None,
    };

    Some(Module { settings, dll })
}

fn load_settings() -> Option<String> {
    None
}

fn load_dll() -> Option<Dll> {
    None
}

Ссылка на Playground

И для Result:

fn main() {
    let module = init_module();
}

struct Module {
    settings: String,
    dll: Dll,
}

struct Dll {}

enum InitModuleError {
    SettingsError(LoadSettingsError),
    DllError(LoadDllError),
}

fn init_module() -> Result<Module, InitModuleError> {
    let settings = match load_settings() {
        Ok(s) => s,
        Err(e) => return Err(InitModuleError::SettingsError(e)),
    };

    let dll = match load_dll() {
        Ok(dll) => dll,
        Err(e) => return Err(InitModuleError::DllError(e)),
    };

    Ok(Module { settings, dll })
}

struct LoadSettingsError {}

fn load_settings() -> Result<String, LoadSettingsError> {
    Err(LoadSettingsError {})
}

struct LoadDllError {}

fn load_dll() -> Result<Dll, LoadDllError> {
    Err(LoadDllError {})
}

Ссылка на Playground

Как видно в примерах, такой подход требует большого количества match конструкций. Это усложняет код, ухудшает его читабельность и добавляет разработчику дополнительной рутинной работы. Во избежание всего этого, создатели языка ввели оператор ?. Расположенный после Option или Result, он заменяет собой match конструкцию. В случае наличия значения, он возвращает его для дальнейшего использования. В случае ошибки, возвращает её из функции. Воспользуемся им в наших примерах. Для Option всё очевидно:

fn main() {
    let module = init_module().unwrap();
}

struct Module {
    settings: String,
    dll: Dll,
}

struct Dll {}

fn init_module() -> Option<Module> {
    let settings = load_settings()?;
    let dll = load_dll()?;
    Some(Module { settings, dll })
}

fn load_settings() -> Option<String> {
    None
}

fn load_dll() -> Option<Dll> {
    None
}

Ссылка на Playground

Для Result всё обстоит немного сложнее. Ведь в случае, если происходит LoadDllError, то компилятору нужно как-то преобразовать её в InitModuleError для возврата из функции. Для этого оператор ? пытается найти способ преобразования для этих ошибок. Для того, чтобы создать такой способ, в стандартной библиотеке существует трейт From. Воспользуемся им:

fn main() {
    let module = init_module();
}

struct Module {
    settings: String,
    dll: Dll,
}

struct Dll {}

enum InitModuleError {
    SettingsError(LoadSettingsError),
    DllError(LoadDllError),
}

impl From<LoadSettingsError> for InitModuleError {
    fn from(e: LoadSettingsError) -> InitModuleError {
        InitModuleError::SettingsError(e)
    }
}

impl From<LoadDllError> for InitModuleError {
    fn from(e: LoadDllError) -> InitModuleError {
        InitModuleError::DllError(e)
    }
}

fn init_module() -> Result<Module, InitModuleError> {
    let settings = load_settings()?;
    let dll = load_dll()?;
    Ok(Module { settings, dll })
}

struct LoadSettingsError {}

fn load_settings() -> Result<String, LoadSettingsError> {
    Err(LoadSettingsError {})
}

struct LoadDllError {}

fn load_dll() -> Result<Dll, LoadDllError> {
    Err(LoadDllError {})
}

Ссылка на Playground

Иными словами, Rust требует явно описывать способы преобразования ошибок друг в друга при передаче их верхним уровням иерархии вызовов.

Динамические ошибки

В случае, если нет необходимости использовать конкретный тип ошибки, а достаточно просто иметь текстовое сообщение о ней, то можно передавать ошибку в виде трейт объекта std::error::Error, завёрнутого в умный указатель Box (подробнее). Трейт Error определён так:

trait Error: Debug + Display {...}

Как видно из определения, он требует реализации трейтов Debug и Display. Таким образом, Rust вводит требования для всех типов реализующих Error: уметь выводить отладочную и текстовую информацию о себе. Рассмотрим на примере:

use std::fmt;
use std::error::Error;

fn main() {
    init_module().unwrap();
}

struct Module {
    settings: String,
    dll: Dll,
}

struct Dll {}

fn init_module() -> Result<Module, Box<dyn Error>> {
    let settings = load_settings()?;
    let dll = load_dll()?;
    Ok(Module { settings, dll })
}

#[derive(Debug)]
struct LoadSettingsError {}

impl Error for LoadSettingsError {}

impl fmt::Display for LoadSettingsError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "load settings error")
    }
}

fn load_settings() -> Result<String, Box<dyn Error>> {
    Err(Box::new(LoadSettingsError {}))
}

#[derive(Debug)]
struct LoadDllError {}

impl Error for LoadDllError {}

impl fmt::Display for LoadDllError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "load dll error")
    }
}

fn load_dll() -> Result<Dll, Box<dyn Error>> {
    Err(Box::new(LoadDllError {}))
}

Ссылка на Playground

Как видно из примера, при использовании динамических ошибок, нет необходимости создавать промежуточные типы ошибок, объединяющие несколько типов ошибок нижнего уровня. У такого подхода есть свои недостатки. Во-первых, отсутствует возможность определить конкретный тип ошибки, произошедшей на нижнем уровне. Во-вторых, снижается производительность, так как для создания ошибки требуется аллокация в куче, а, при выводе сообщения об ошибке, используется динамическая диспетчеризация.

Полезные библиотеки

Рассмотрим две популярные библиотеки, упрощающие обработку ошибок: thiserror и anyhow.

thiserror

Данная библиотека предоставляет макросы, позволяющие упростить рутинные действия: описание способов конвертации ошибок через From, и реализация трейтов Error и Display. Рассмотрим на примере:

use thiserror::Error; // 1.0.29

fn main() {
    let module = init_module().unwrap();
}

struct Module {
    settings: String,
    dll: Dll,
}

struct Dll {}

#[derive(Debug, Error)]
enum InitModuleError {
    #[error("init module settings error")]
    SettingsError(#[from] LoadSettingsError),
    #[error("init module dll error")]
    DllError(#[from] LoadDllError),
}

fn init_module() -> Result<Module, InitModuleError> {
    let settings = load_settings()?;
    let dll = load_dll()?;
    Ok(Module { settings, dll })
}

#[derive(Debug, Error)]
#[error("load settings error")]
struct LoadSettingsError {}

fn load_settings() -> Result<String, LoadSettingsError> {
    Err(LoadSettingsError {})
}

#[derive(Debug, Error)]
#[error("load dll error")]
struct LoadDllError {}

fn load_dll() -> Result<Dll, LoadDllError> {
    Err(LoadDllError {})
}

Ссылка на Playground

В данном примере, трейт Error реализуется автоматически с помощью макроса #[derive(Error)]. Используя макрос #[error("text to display")] генерируем реализацию трейта Display. Макрос #[from] создаёт реализацию трейта From для конвертации ошибки нижнего уровня в ошибку текущего.

Данные макросы значительно сокращают объём boilerplate кода для обработки ошибок.

anyhow

Данную библиотеку удобно использовать, когда единственное, что интересует нас в ошибке — её текстовое описание. anyhow предоставляет структуру Error. В неё может быть сконвертирован любой объект, реализующий трейт std::Error, что значительно упрощает распространение ошибки по иерархии вызовов. Помимо этого, anyhow::Error позволяет добавлять текстовое описание контекста, в котором произошла ошибка. Эта библиотека сочетается с thiserror. Пример:

use thiserror::Error; // 1.0.29
use anyhow; // 1.0.43;
use anyhow::Context; // 1.0.43;

fn main() {
    let module = init_module().unwrap();
}

struct Module {
    settings: String,
    dll: Dll,
}

struct Dll {}

fn init_module() -> anyhow::Result<Module> {
    let dll = load_dll().context("module initialization")?;
    let settings = load_settings()?;
    Ok(Module { settings, dll })
}

#[derive(Debug, Error)]
#[error("load settings error")]
struct LoadSettingsError {}

fn load_settings() -> Result<String, LoadSettingsError> {
    Err(LoadSettingsError {})
}

fn load_dll() -> anyhow::Result<Dll> {
    anyhow::bail!("load dll error")
}

Ссылка на Playground

Макрос anyhow::bail!() в примере создаёт anyhow::Error с заданным описанием и возвращает её из функции. Псевдоним anyhow::Result определяется так:

type Result<T, E = Error> = Result<T, E>;

Заключение

В начале статьи мы рассмотрели три возможных варианта действий, при получении ошибки: завершить работу программы, обработать ошибку и передать ошибку вверх по иерархии вызовов. Далее, разобравшись с особенностями синтаксиса, мы разобрались на примерах, как выразить наши намерения по отношению к ошибке на языке Rust. Мы увидели, что любой из вариантов поведения должен быть выражен явно. Такой подход повышает надёжность приложения, так как не позволяет разработчику случайно проигнорировать ошибку. С другой стороны, явное описание своих намерений требует дополнительных усилий. Минимизировать эти усилия позволяют библиотеки thiserror и anyhow.

Благодарю за внимание. Поменьше вам ошибок!

Статья написана в преддверии старта курса Rust Developer. Приглашаю всех желающих на бесплатный урок, в рамках которого на примере построения простого веб сервиса рассмотрим популярный веб-фреймворк actix-web в связке с MongoDB + Redis и другие полезные библиотеки для backend разработки.

• Записаться на бесплатный урок

1. netsh winsock reset
2. netsh int ip reset
3. ipconfig /release
4. ipconfig /renew

Остается только перезагрузить браузер.

Способ 4: сканируем компьютер на наличие вирусов

Возможно, в систему закралось вредоносное ПО. Это легко исправить с помощью любого популярного антивируса. Даже Защитник Windows должен справиться со своей задачей.

Способ 5: сбрасываем настройки браузера

Это должно сработать у большинства пользователей, но заранее лучше включить синхронизацию данных с сервером и удалить аккаунт. Принцип сброса прост:

1. Переходим в «Настройки» браузера через основное меню.
2. Листаем список в самый конец, для этого придется открыть «Дополнительные настройки».
3. Жмем на элемент «Восстановление настроек по умолчанию» или «Сброс».
4. Подтверждаем намерение.

Теперь нужно проверить, работает ли reCAPTCHA. Скорее всего все заработало и сейчас самое время вернуть свои данные, выполнив синхронизацию с серверами.

не удается связаться с сервисом recaptcha: что делать?

Некоторые сайты не загружаются без введения капчи. ReCAPTCHA, к сожалению, периодически не работает в Chrome и других браузерах. Давайте рассмотрим, почему может не отображаться капча и как это исправить.

ReCAPTCHA: что это такое

При попытке открыть отдельные веб-страницы появляется сообщение: «Подтвердите, что вы не бот».

За проверку пользователей отвечает ReCAPTCHA – бесплатная служба Google. Она помогает избежать перегрузки серверов, поскольку делает невозможным использование автоматизированных инструментов для веб-серфинга и/или рассылки спама.

Суть функционирования сервиса простая: пользователь входит на сайт и видит окно, в котором нужно выбрать определенные картинки, например, изображения автобусов. Так посетитель ресрурса подтверждает, что является человеком.

Случается, что ReCAPTCHA не работает в Chrome и других браузерах. Появляется оповещение о неудачной проверке. Как результат, веб-страница не открывается.

Причины сбоев в работе ReCAPTCHA

Единой причины, по которой капча может не работать, не существует. Есть несколько возможных проблем и способов их решения.

Использование прокси или VPN

Мы активно используем VPN и прокси-серверы для обхода блокировки любимых сайтов и для сохранения конфиденциальности. Однако это – частая причина проблем с работой сервиса ReCAPTCHA. Подключение через сторонние серверы не дает корректно определить, являемся ли мы человеком, а не роботом.

Устаревший браузер

Частая причина проблем с ReCAPTCHA – использование устаревшего браузера. Программное обеспечение, не обновленное вовремя, становится источником большого числа ошибок при веб-серфинге.

Вредоносное программное обеспечение

Случается, что причиной проблем с отображением капчи становятся вирусы и другое вредоносное ПО. Софт, используемый хакерами, негативно влияет на функционирование браузера и системы в целом.

Подозрительный IP-адрес

Капча работает некорректно, если сайт определяет, что у человека подозрительный IP-адрес. Обычно это происходит при включенном VPN или при подключении к общественной сети Wi-Fi с большим количеством пользователей.

Как устранить неполадки с ReCAPTCHA

Проблемы с работой ReCAPTCHA легко решаемы. Зная, как с ними справиться, вы без проблем сможете посещать любые сайты.

Используйте брандмауэер и антивирус

Защитить компьютер от вредоносного софта помогает использование антивируса и брандмауэера. Антивирусный софт должен быть актуальным.

Обновите браузер и систему в целом

Постоянно обновляйте браузер и операционную систему. В устаревших версиях ПО появляются уязвимости и сбои, используемые хакерами.

Контролируйте использование VPN

Если при использовании VPN отдельные сайты не работают, отключите сервис. Как результат, веб-страница откроется.

Сбросьте IP

В Windows IP можно сбросить из командной строки. Для этого нужно использовать следующую команду: ipconfig /renew.

Перезагрузите роутер

Маршрутизатор может неправильно обрабатывать запросы. Для устранения этой проблемы достаточно выключить роутер, подождать 30 секунд, а затем снова включить устройство.

Если recaptcha не работает

Создание сайта

На днях столкнулся с проблемой, обнаружив некоторое количество спама в почте и тем, что recaptcha не работает на всех сайтах, где установлена форма на базе Contact Form 7. Обновление ключей и секретов на сайте reCaptcha ничего не дало. Решение нашлось далеко не сразу, на одном из наших форумов и оно весьма простое.

Инструкция по устранению неполадок в работе reCaptcha в Contact Form 7

Ниже прилагается довольно простая инструкция по устранению неполадок в работе reCaptcha в Contact Form 7.
1. Первым делом устанавливаем плагин Contact Form 7 Captcha.
2. Берем ключи на сайте Google reCAPTCHA.
3. Размещаем ключи в настройках плагина Contact Form 7 Captcha и сохраняем.
4. Берем шорткод [ cf7sr-simple-recaptcha ] в Contact Form 7 Captcha и вставляем в то место нашей формы, где ранее размешался шорткод [ recaptcha ]. Сохраняем и проверяем работоспособность обновленной формы.

Если капча есть но форма не работает

Если после проведения работ согласно инструкции представленной выше капча стала отображаться, но при отправке появляется сообщение об ошибке, то попробуйте сделать следующее:
1. Удалите кеш (если у вас стоит плагин кеширования);
2. Удалите ключ в разделе Интеграция и замените в прочих формах, созданных вами ранее, шорткоды recaptcha на cf7sr-simple-recaptcha. После этого снова проверьте работу формы. Это все.