Un usuario preguntó 👇
Hola, configuré tu plugin hoy, ¡y es genial! El único problema que tengo, y la solución que tengo que hacer, es que no puedo borrar la dirección IP de mi servidor nativo porque estoy usando un compilador en la nube. Recibo este mensaje de error cuando agrego ip a mis servidores nativos con la configuración de la lista blanca. (Muestra una IP diferente cada vez que se prueba una conexión, debido a un proxy inverso en la nube, creo).
«Se produjo el siguiente error en el sitio web remoto: acceso no autorizado (dirección IP remota no válida 172.69.22.52)»
¿Hay alguna forma de especificar las clases de IP de Cloudflare en la configuración de seguridad de la lista blanca de este plugin?
https://www.cloudflare.com/ips-v4 (Los agregué tal como estaban en este enlace). ¿Quizás lo hice mal?
¿O cree que una mejor manera de abordar los problemas de direcciones IP es crear una nube de reglas de firewall de bypass en silueta y poner las direcciones IP de mis servidores de origen en la ubicación en blanco?
https://developers.cloudflare.com/firewall/cf-firewall-rules/actions/
Si paso por alto, supongo que creo una regla para omitir los ips de cloudflare para los puntos finales / wprus
https://website1.com/wprus/*
https://website2.com/wprus/*
No estoy seguro de estar a la altura de la regla del firewall.
(@frogerme)
Hace 8 meses, 1 semana
Hola @kittcatalina!
Gracias por la sugerencia, ¡me alegra que sea útil para ti!
En uno de mis sitios de prueba, en realidad estoy usando Cloudflare, con ambos sitios marcados como «Proxied» en la tabla de administración de DNS (https://dash.cloudflare.com/%5Btoken%5D/
[domain]/ dns). Luego verifiqué las IP que se muestran en los registros de plugins y las puse en el lister, y logré vincular los sitios. Mirando las cosas un poco más de cerca, noté que las direcciones IP que se muestran en los registros nunca cambiaron, y en realidad eran la dirección IP del servidor de origen: el Proxy parecía no tener ningún efecto en la conectividad del sitio por mi parte.
Ahora, no estoy seguro de cuáles son las configuraciones para que termines con Cloudflare, pero lo que entiendo es que la dirección IP en tu caso cambia todo el tiempo, y eso obviamente es un problema desde REMOTE_ADDR es lo que verifica el plugin.
Actualmente (y no estoy seguro de que deba / lo hará), el lister no acepta rangos de IP. Pero no creo que la solución de la regla de derivación funcione: /wprus
es el punto final, no el remitente de la solicitud; comprueba la IP correspondiente a la URL de la página donde se envía la solicitud :(.
Ahora, para ofrecer un mayor nivel de flexibilidad, estoy agregando un nuevo filtro (apply_filters( 'wprus_is_authorized_remote', (bool) $is_authorized_remote, (string) $method, (string) $remote_addr, (mixed) $ip_whitelist );
) a la siguiente versión. De esta manera, el comportamiento de validación se puede personalizar mediante el uso de un plugin personalizado, que puede ser su apuesta segura (le permitiría implementar la validación del rango de IP, por ejemplo).
Espero que ayude, o la adición en 1.1.12 ayudará.
(@frogerme)
Hace 8 meses, 1 semana
Hola @kittcatalina!
Se presiona la versión 1.1.12 y el nuevo filtro está allí wprus_is_authorized_remote
.
(@kittcatalina)
Hace 8 meses, 1 semana
¡Muchas gracias, Alexandre!
¡Veré qué puedo hacer con el filtro wprus_is_authorized_remote más tarde mañana!
Lo encontré funcionando perfectamente hace solo unos minutos con algunas configuraciones en los servidores que había arreglado.
Una solución fue ajustar la configuración dentro del panel del servidor OpenLiteSpeed Webadmin.
Publicaré esto aquí en caso de que también sea útil para alguien.
En el panel de OpenLitespeed Webadmin … 1.) Vaya a Configuración del servidor >> Configuración general y cambie la configuración «Usar encabezado de IP del cliente» a «IP de confianza» o «Sí». 2.) Si selecciona «Sí», entonces todos alguna cosa. La IP de origen se completará perfectamente en WP Remote User Sync. 3.) Si selecciona “Solo IP de confianza”, vaya a Configuración del servidor >> Seguridad >> Control de acceso y agregue las subsidiarias de Cloudflare y los rangos de IP con T siguiendo la IP. (Los envié sin el Tanna primero y esto no funcionó hasta que leí los documentos).
Esta fue la documentación que me ayudó a resolver esto. 1.) https://openlitespeed.org/kb/show-real-visitor-ip-instead-of-cloudflare-ips/
2.) https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs-Logging-visitor-IP-addresses-with-mod-cloudflare-
3.) https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:config:waf:trusted-ip-in-htaccess
Gracias por responder a mi solicitud de soporte y gracias nuevamente por impulsar el lanzamiento.
Esta respuesta fue modificada hace 8 meses, hace una semana por.
(@frogerme)
Hace 8 meses, 1 semana
¡Hola @kittcatalina! ¡Muchas gracias por los comentarios y me alegro de que lo hayan hecho funcionar! Voy a seguir adelante y cerrar la pregunta.
¡Salud!
(@theinnographer)
Hace 5 meses, 1 semana
Hola Alexandre,
Espero que estés bien. (Gracias por realizar estos cambios en la versión 1.2 que ya comentamos aquí: https://wordpress.org/support/topic/fire-sync-on-wp_useradd_role. Se lo agradecemos).
Le escribo para continuar con el tema anterior entre usted y Katherine. Nuestros sitios se sincronizaban maravillosamente hasta que actualizamos recientemente para usar Cloudflare.
Nuestra configuración es mainsite.com y subdominio.mainsite.com, es decir, sincronizando entre ellos.
Desde la introducción de Cloudflare, los botones de prueba en subdomain.mainsite.com han permanecido bloqueados, como siempre. A continuación, se muestra un ejemplo de inicio de sesión presionando los botones de prueba Enter Actions:
2020-08-09 02:05:22 - Success - Ping success for action "Logout" from https://www.mainsite.com with remote IP ##.###.###.### (outgoing)
2020-08-09 02:05:27 - Success - Ping success for action "Login" from https://www.mainsite.com with remote IP ##.###.###.### (outgoing)
2020-08-09 02:05:32 - Success - Ping success for action "Logout" from https://www.mainsite.com with remote IP ##.###.###.### (outgoing)
2020-08-09 02:05:35 - Success - Ping success for action "Update" from https://www.mainsite.com with remote IP ##.###.###.### (outgoing)
2020-08-09 02:05:38 - Success - Ping success for action "Password" from https://www.mainsite.com with remote IP ##.###.###.### (outgoing)
2020-08-09 02:05:42 - Success - Ping success for action "Roles" from https://www.mainsite.com with remote IP ##.###.###.### (outgoing)
Todo bien.
Pero obtenemos errores con las pruebas en mainsite.com como una ventana emergente que dice: La acción «Cerrar sesión» no está activada en https://subdomain.mainsite.com con IP remota ##. ###. ###. ### (entrante) .. Y esto es lo que dice el inicio de sesión en subdomain.mainsite.com después de presionar los mismos botones de prueba salientes en mainsite.com:
2020-08-09 02:08:33 - Success - Ping received for activated action "Login" from https://www.mainsite.com with remote IP ##.###.###.### (incoming)
2020-08-09 02:08:37 - Success - Access granted - https://www.mainsite.comm
2020-08-09 02:08:37 - Warning - Ping received for deactivated action "Logout" from https://www.mainsite.com with remote IP ##.###.###.### (incoming)
2020-08-09 02:08:44 - Success - Access granted - https://www.mainsite.com
2020-08-09 02:08:44 - Warning - Ping received for deactivated action "Update" from https://www.mainsite.com with remote IP ##.###.###.### (incoming)
2020-08-09 02:08:50 - Success - Access granted - https://www.mainsite.com
2020-08-09 02:08:50 - Warning - Ping received for deactivated action "Password" from https://www.mainsite.com with remote IP ##.###.###.### (incoming)
2020-08-09 02:08:55 - Success - Access granted - https://www.mainsite.com
2020-08-09 02:08:55 - Warning - Ping received for deactivated action "Roles" from https://www.mainsite.com with remote IP ##.###.###.### (incoming)
Las pruebas de actividad salientes son buenas en subdomain.mainsite.com. pero las pruebas de actividad entrantes crean los mismos tipos de errores en mainsite.com.
¿Esto parece estar en línea con la introducción de Cloudflare en el dominio?
Y si es así, ¿podría proporcionar un ejemplo de cómo utilizar el filtro wprus_is_authorized_remote? Podemos agregarlo a nuestro plugin, pero no estoy 100% seguro del uso. Un gran ejemplo sería.
¿Es inusual que (solo) las acciones de inicio de sesión funcionen en ambos sentidos? Esto implica que la configuración del sitio sigue siendo válida. (Lo que tiene sentido es que no cambiaron en absoluto, no los tocamos y nunca tocamos las otras acciones como inicio de sesión, actualización, contraseña y roles).
Finalmente, ¿podría este comportamiento correlacionarse con algo más? Recientemente cambiamos los plugins de caché (aunque no noté este problema en ese momento). Pero una versión renovada del sitio precede ese cambio de la misma manera.
Gracias por tu ayuda.
Alex.
(@theinnographer)
Hace 5 meses, 1 semana
Hola de nuevo,
Siga rápido que desactivamos Cloudflare y parecía que volvíamos a la recuperación. Entonces esa parece ser nuestra pregunta, si no me falta algo.
Definitivamente agradecería su orientación sobre cómo configurar las cosas con Cloudflare, así que ahí es donde queremos llegar.
He leído lo anterior y estoy tratando de darle sentido, pero ciertamente entiendo un resumen de lo que se requiere, p. Ej. el filtro wprus_is_authorized_remote por sí solo, o eso más algunas configuraciones de Cloudflare, etc…?
Y algunas orientaciones / ejemplos más específicos podrían ser muy útiles para mí y para otros.
¡Gracias de nuevo!
Alex.
(@frogerme)
Hace 5 meses, 1 semana
Hola @theinnographer,
Cuando se activa Cloudflare, ¿existen discrepancias entre las URL que se muestran en los registros y las que se encuentran en el wp_options
¿mesas? «Advertencia: Ping recibido para la actividad de desactivación …» generalmente ocurre porque la URL recibida en la carga útil transferida desde el sitio remoto no coincide con la URL local en la configuración de WPRUS, y es probable que los protocolos de URL sean inconsistentes. También estoy usando Cloudflare en mi entorno de prueba, y especialmente en su función https: tuve el mismo problema y tuve que actualizar la configuración de WordPress para asegurarme de que la sincronización funcionara.
Tenga en cuenta que en su caso, utilizando wprus_is_authorized_remote
no ayudaría en absoluto, ya que los mensajes «Success – Grant deon Access» ya se muestran en los registros; la solicitud ya está autorizada, no puede encontrar una coincidencia entre la carga útil y la ubicación con la información coincidente en la configuración de WPRUS.
(@theinnographer)
Hace 5 meses, 1 semana
Hola Alexandre,
Gracias por la rápida respuesta.
Con base en esta información, me pregunto si ese fue el problema que tuvimos cuando activamos Cloudflare, ya que entiendo que hace que el sitio sea accesible a través de www …
Y luego, desactivarlo, lo devolvió para que volviéramos a tener razón.
Considerándolo más a fondo, tiene sentido (¿creo?) Que no hayamos abordado ese problema, no solo por lo que indica, sino porque nuestros dos sitios están en el mismo dominio e IP. .
Con ganas de activar Cloudflare (y pasar a un sitio de prueba desde el subdominio), ¿puedo interrumpirlo como ejemplo del uso de wprus_is_authorized_remote? Solo quiero asegurar mis notas sobre eso con anticipación antes de abordarlo la próxima semana.
¡Gracias de nuevo!
Alex.
(@frogerme)
Hace 5 meses, 1 semana
@theinnographer, entonces usted va – para ser agregado a un archivo principal de plugin personalizado, por ejemplo:
add_filter( 'wprus_is_authorized_remote', 'wprus_is_authorized_remote_filter', 10, 4 )
function my_ wprus_is_authorized_remote_filter(
$is_authorized_remote,
$method,
$remote_addr,
$ip_whitelist
) {
// your logic here, for example a code checking IP range, bypassing the $ip_whitelist check
if ( myfunction_ip_is_in_range( $remote_addr ) ) {
return true;
}
return $is_authorized_remote;
}
Y en cuanto a Cloudflare: si te entiendo bien, si tu dominio no fue previamente accesible a través de www, pero está disponible mágicamente a través de Cloudflare, será mejor que te asegures de tener una versión www de la URL. wp_options
mesa. Es muy probable que de ahí provenga la pregunta.
Esta respuesta fue modificada hace 5 meses, hace una semana por.
(@theinnographer)
Hace 5 meses, 1 semana
Gracias de nuevo @frogerme. Excelente.
Y para dejar claro a los demás, esto podría ayudar. El sitio del dominio principal no estaba visible en www. antes de Cloudflare pero luego fue visto después. Y la información funcionó antes de Cloudflare, no funcionó con ella y funcionó nuevamente después de que se desactivó.
¿Solucionó tu problema??
0 / 0