Comunicados

ReportedIP 2.0.16 — Límite de frecuencia promocional y correos de alerta de cuotas

27 de mayo de 2026 · Patrick Schlesinger

ReportedIP 2.0.16 agrupa todas las sugerencias de actualización bajo un único límite de frecuencia, añade correos de alerta sobre el límite de retransmisión al alcanzar el 80 % y el 100 %, y corrige una serie de errores relacionados con la reactivación del «modo de refuerzo» y la retracción de retransmisión. Se trata de una versión estable que se distribuye a través de la comprobación de actualizaciones integrada cada 12 horas.

Los sitios configurados para la actualización automática la recibirán en un plazo de doce horas. Para descargarla ahora, fuerza una comprobación a través de Dashboard → Actualizaciones o descarga la versión etiquetada desde GitHub.

Cómo afecta el límite promocional unificado a Hive 2.0.16 para los administradores del plan gratuito

Una nueva clase, ReportedIP_Hive_Promo_Manager, es ahora la única fuente de referencia para la pregunta «¿se puede mostrar ahora esta sugerencia de actualización?». Todas las superficies promocionales pasan por ella: el banner de 2FA de WooCommerce, la tarjeta de venta adicional integrada de 2FA en la interfaz de usuario, la tarjeta del panel de control de retransmisión de correo/SMS y el bloque de información del modo de refuerzo. Antes de la versión 2.0.16, cada una de ellas tenía su propio tiempo de espera ad hoc y podían acumularse.

El director aplica cuatro normas a la vez:

• Límite global de 90 días por administrador en todas las plataformas promocionales.
• Período de espera de 60 días tras un despido, según cada función.
• Opción de exclusión permanente por usuario con un enlace «No volver a mostrar esto».
• Un interruptor de desactivación en Ajustes → Notificaciones que oculta todas las sugerencias de actualización de una sola vez.

El resultado final: un administrador del plan gratuito ve, como mucho, unas cuatro promociones discretas al año. La actualización también eliminó una tarjeta de venta adicional duplicada de «Frontend-2FA» que no tenía business en la pestaña «Modo de refuerzo», y aumentó el Two_Factor_Recommend Se ha ampliado el tiempo de espera para cerrar el banner de aviso de 30 minutos a 14 días. El proceso de incorporación con bloqueo estricto para los roles con privilegios no ha sufrido cambios: las recomendaciones de seguridad siguen primando sobre la comodidad.

Ahora recibirás las alertas sobre cuotas de retransmisión por correo electrónico

Una nueva ReportedIP_Hive_Quota_Notifier evalúa la instantánea de la cuota de retransmisión tras cada actualización programada de seis horas. Cuando un canal supera el 80 % o el 100 % de su asignación mensual, envía un correo electrónico informativo a la lista de destinatarios de alertas. Cada canal y cada etapa tiene un periodo de espera de 30 días, y dicho periodo se reinicia automáticamente con cada nuevo periodo de facturación (el period_start (cambio), por lo que al comenzar un nuevo mes se reinician las alertas.

También hay una aplicación integrada en el panel de control. Cuando el servicio de reenvío de correo electrónico o SMS devuelve un código HTTP 402 (límite mensual) o 429 (restricción por parte del destinatario o del sitio), el proveedor marca una reportedip_hive_relay_cap_state_* site-transient. Las páginas de administración muestran entonces un aviso de advertencia no promocional —que se puede cerrar durante 24 horas— en el que se explica que, actualmente, los correos electrónicos se redirigen a wp_mail() y la autenticación de dos factores por SMS está desactivada, con un enlace a los detalles del límite. La siguiente vez que se inicie sesión con éxito /relay-quota Una actualización que muestre que el uso está por debajo del límite borra el estado automáticamente.

Si hay cambios en el plan, envía un correo electrónico breve y conciso

Tier_Upgrade::on_tier_changed Ahora gestiona tanto las actualizaciones como las downgrades. En caso de downgrade, borra el estado obsoleto del banner posterior a la actualización, desactiva temporalmente el interruptor de «WooCommerce Frontend-2FA» —tus datos se conservan, por lo que una futura nueva actualización se realizará sin problemas— y envía un breve correo electrónico informativo. Las actualizaciones activan un correo de bienvenida correspondiente que indica los pasos de configuración restantes. Ambos correos pueden desactivarse mediante el nuevo interruptor situado en Ajustes → Notificaciones.

En la versión 2.0.16, la pestaña de configuración incorpora tres opciones: ocultar todas las sugerencias de actualización (desactivada por defecto; las sugerencias permanecen activadas), enviar un correo electrónico cuando el límite de tráfico del relé alcance el 80 % o el 100 %, y enviar un correo electrónico cuando cambie el plan. Las recomendaciones de seguridad y los avisos sobre el estado operativo no se ven afectados por ninguna de estas opciones.

Correcciones en el modo de endurecimiento y en el retardo del relé

El modo de endurecimiento ya no se reactiva automáticamente dentro del periodo de revisión de 2 horas

Tras una caducidad natural o una desactivación por parte del administrador, el modo de refuerzo podría reactivarse si el mismo intervalo de minutos se encontrara aún dentro del periodo de revisión de SQL de dos horas. El por-time_window El marcador ahora almacena la carga útil canónica de la razón más sólida en lugar de un indicador de presencia, por lo que la supresión se mantiene tras el borrado diferido de TRANSIENT_REASON en is_active() y el borrado explícito en deactivate(). Un deactivate('admin') Ahora, la anulación también borra el marcador de la ventana de «Live Reason», por lo que la anulación se mantiene.

También se ha corregido un error relacionado con la extensión TTL-low: TRANSIENT_REASON solía caducar mientras las prórrogas por horas seguían acumulándose TRANSIENT_UNTIL, y la siguiente barrida semanal anuló el desencadenante más potente original. La rama de extensión ahora actualiza el TTL del marcador junto con TRANSIENT_UNTIL y registra un marcador para la ventana del candidato, de modo que un barrido posterior no pueda activarse por segunda vez hardening_mode_extended registro del mismo depósito.

Los eventos de ataque coordinado se activan una vez por patrón, no una vez por ciclo de cron

Security_Monitor::check_coordinated_attacks() ahora escribe un marcador de registro de 2 horas por time_window, por lo que la estructura coordinated_attack_detected Los eventos críticos se activan una vez por patrón, en lugar de una vez por ciclo de cron. cron_sync_reputation() ya no registra un duplicado Coordinated attacks detected Además de eso, el ruido del registro de actividad por hora, que en un registro de cambios anterior se atribuía al envoltorio de cron, procedía en realidad de este flujo interno.

El tiempo de espera del relé 429 ahora se aplica a toda la red y respeta el parámetro «Retry-After»

El tiempo de espera de relay-mail y relay-sms 429 se ha cambiado a set_site_transient (en toda la red en entornos multisitio), conserva el código de estado HTTP original en la carga útil del periodo de espera y analiza la fecha HTTP Retry-After cabezales correctamente, y limita el tiempo de recarga a DAY_IN_SECONDS en lugar de una hora. Cada una de ellas corrige un comportamiento real observado en producción: los transitorios por blog permitían que tres subsitios agotaran de forma independiente el límite del servidor por destinatario; un error 429 sintético enmascaraba un límite mensual 402 como un mensaje de «demasiados envíos» y ocultaba la solicitud de actualización; una fecha HTTP Retry-After convertir a (int) se redujo a 0 y volvió al valor predeterminado de 5 minutos; y el límite de una hora generó consultas cada hora, con un límite máximo de 24 horas por servidor.

Pequeñas correcciones de errores

• Ya se ha escrito el código SMS de autenticación de dos factores después de el proveedor acepta el envío. Una escritura previa al envío dejó hash de código obsoletos en _transient_rip_2fa_sms_code_<user> durante diez minutos, cuando el relé sufrió un cortocircuito debido al retroceso del cliente.
• Los niveles «Enterprise» y «Honeypot» ya no se incluyen en la cola no_quota cortocircuito cuando los sellos de origen remaining_reports = 0 en una cuenta ilimitada. Un plan compartido quota_is_unlimited() El asistente ahora controla ambos has_report_quota() y get_quota_status().
• La acción de administración «Enviar correo de prueba» muestra un banner cuando el servidor de retransmisión recurre a wp_mail(), utilizando un nuevo ReportedIP_Hive_API::is_relay_in_backoff() comprueba para saber si realmente has validado la ruta de retransmisión gestionada.
• Ahora, al desinstalar un complemento, se borran los datos temporales del mismo. delete_all_plugin_options solo coincidentes option_name LIKE 'reportedip_hive_%', que se saltó el _transient_… y _site_transient_… filas; de lo contrario, esas claves permanecerían tras la desinstalación y causarían problemas en una nueva instalación.
• El menú desplegable de la interfaz de usuario de «Logs» ahora muestra hardening_mode_extended y el estructurado coordinated_attack_detected tipos de eventos como filtros.

Cómo actualizar a la versión 2.0.16

• Actualización automática desde el propio plugin. El Plugin Update Checker consulta GitHub Releases cada 12 horas. Si no quieres esperar, puedes forzar una comprobación desde el Panel de control → Actualizaciones.
• Descarga manual. Descarga el archivo ZIP de la versión 2.0.16 en GitHub.
• WP-CLI. wp plugin update reportedip-hive si gestionas WordPress desde la línea de comandos.

Para consultar la versión anterior y el historial completo de versiones, consulta las notas de la versión 2.0.15 y el registro de cambios de la API y los complementos. La instalación y la configuración se describen en la documentación del complemento de WordPress.

Consigue ReportedIP →