ReportedIP Hive 2.0.16 — Correos electrónicos de alerta sobre límites de frecuencia y cuotas promocionales
ReportedIP Hive 2.0.16 agrupa todas las notificaciones de actualización bajo un único límite de frecuencia, añade correos de alerta sobre el límite de relés al alcanzar el 80 % y el 100 %, y corrige una serie de errores relacionados con la reactivación del «Hardening Mode» y la reducción de la frecuencia de los relés. Esta versión es estable y 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 Free tier
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 Frontend 2FA en la interfaz de usuario, la tarjeta del Dashboard de SMS Relay y el bloque de información del Hardening Mode. 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, que varía según la función.
- Opción de exclusión permanente por usuario con un enlace que diga «No volver a mostrar esto».
- Opción 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 Free tier 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 por qué aparecer en la pestaña «Hardening Mode», y aumentó el Two_Factor_Recommend tiempo de espera para cerrar el banner suave de 30 minutos a 14 días. La ruta de incorporación con bloqueo estricto para los roles con privilegios no ha sufrido cambios: una recomendación de seguridad sigue teniendo prioridad 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 de cron cada 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 fase tienen 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 de mes), por lo que al comenzar un nuevo mes se reinician las alertas.
También hay una función complementaria integrada en el Dashboard. Cuando el servicio de reenvío de correo electrónico o SMS Relay devuelve un código HTTP 402 (límite mensual) o 429 (restricción por destinatario o sitio web), el proveedor marca un reportedip_hive_relay_cap_state_* . A continuación, las páginas de administración muestran un aviso de advertencia no promocional —que se puede cerrar durante 24 horas— en el que se explica que, actualmente, los correos recurren a wp_mail() y que la autenticación 2FA por SMS está pausada, con un enlace a los detalles de la cuota. La siguiente /relay-quota que muestre un uso por debajo del límite borra este estado automáticamente.
Si hay cambios en el plan, envía un correo breve y conciso con la información relevante
Tier_Upgrade::on_tier_changed Ahora gestiona tanto las actualizaciones como las bajadas de versión. Al realizar una bajada de versión, borra el estado obsoleto del banner posterior a la actualización, desactiva temporalmente el botón de activación del Frontend 2FA de WooCommerce en la interfaz de usuario —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 en Ajustes → Notificaciones.
En la versión 2.0.16, la pestaña de configuración incorpora tres opciones de activación/desactivación: 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 deliberadamente por ninguna de estas opciones.
Correcciones en Hardening Mode y en el retardo del relé
Hardening Mode 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 «Hardening Mode» podría reactivarse si el mismo intervalo de un minuto se encontrara aún dentro del periodo de revisión de SQL de 2 horas. El marcador portime_window marcador almacena ahora la Payload canónica de la razón más sólida en lugar de un indicador de presencia, de modo que la supresión sobrevive al borrado diferido de TRANSIENT_REASON en is_active() y el borrado explícito en deactivate(). Una deactivate('admin') anulación también borra ahora el marcador para la ventana del motivo activo, de modo que la anulación se mantenga.
También se ha corregido un error relacionado con la extensión «TTL-low»: TRANSIENT_REASON solía caducar mientras las extensiones por hora seguían actualizándose TRANSIENT_UNTIL, y el siguiente barrido débil anulaba entonces el disparador original más fuerte. La rama de extensión ahora actualiza el TTL del marcador al mismo tiempo que TRANSIENT_UNTIL y registra un marcador para la ventana del candidato, de modo que un barrido posterior no pueda activar un segundo hardening_mode_extended registro para el mismo compartimento.
Los eventos de ataque coordinado se activan una vez por patrón, no una vez por tick de cron.
Security_Monitor::check_coordinated_attacks() ahora escribe un marcador de registro de 2 horas por time_window, de modo que el evento crítico estructurado coordinated_attack_detected se activa una vez por patrón, en lugar de una vez por ciclo de cron. cron_sync_reputation() Ya no registra un Coordinated attacks detected agregado duplicado además de eso; el ruido del registro de actividad por hora que un Changelog anterior atribuía al envoltorio de cron era, de hecho, 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 del código de estado 429 de «Mail Relay» y «SMS Relay» pasó a set_site_transient (a nivel de red en entornos Multisite), conserva el código de estado HTTP original en la Payload del periodo de espera, analiza correctamente los encabezados HTTP-date Retry-After correctamente y limita el tiempo de espera a DAY_IN_SECONDS en lugar de una hora. Cada una de estas medidas corrige un comportamiento real observado en producción: los transitorios por blog permitían que tres subsitios saturaran de forma independiente el límite del servidor por destinatario; un 429 sintético enmascaraba un límite mensual 402 como un mensaje de «demasiados envíos» y ocultaba la solicitud de actualización; un Retry-After se reducía a (int) se reducía a 0 y recurría al valor predeterminado de 5 minutos; y el límite de una hora generaba comprobaciones cada hora frente a un límite del servidor de 24 horas.
Pequeñas correcciones de errores
- El código SMS de autenticación de dos factores (2FA) ahora se escribe una vez que el proveedor ha aceptado el envío. Una escritura previa al envío dejaba hashes de código obsoletos durante
_transient_rip_2fa_sms_code_durante diez minutos cuando el relé se cortocircuitaba debido al retraso del cliente. - Los niveles «Enterprise» y «Honeypot» ya no provocan un
no_quotase producen cortocircuitos cuando los sellos de origenremaining_reports = 0en una cuenta Unlimited. Unquota_is_unlimited()auxiliar ahora controla amboshas_report_quota()yget_quota_status(). - La acción de administración «Enviar correo de prueba» muestra un banner cuando el relé ha recurrido a
wp_mail(), utilizando una nuevaReportedIP_Hive_API::is_relay_in_backoff()prueba, para que sepas si realmente has validado la ruta del relé gestionado. - Ahora, al desinstalar un complemento, se borran los datos transitorios del mismo.
delete_all_plugin_optionssolo coincidíaoption_name LIKE 'reportedip_hive_%', lo que hacía que se omitiera el_transient_…y_site_transient_…; de lo contrario, esas claves permanecerían tras la desinstalación y podrían causar problemas en una nueva instalación. - El menú desplegable de la interfaz de usuario de «Logs» ahora muestra
hardening_mode_extendedy loscoordinated_attack_detectedcomo filtros.
Cómo actualizar a la versión 2.0.16
- Actualización automática desde el propio complemento. El «Plugin Update Checker» consulta GitHub Releases cada 12 horas. Si no quieres esperar, puedes forzar una comprobación desde el Dashboard → Actualizaciones.
- Descarga manual. Descarga el archivo ZIP de la versión 2.0.16 en GitHub.
- WP-CLI.
wp plugin update reportedip-hivesi 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 Changelog de la API y los complementos. La instalación y la configuración se describen en la documentación de los complementos de WordPress.