Incrustado La solicitud fue bloqueada por DoSP

Hola a todos,

He estado siguiendo esto porque tengo el mismo problema y he estado probando todo el día.
Logré que funcionara usando un tiempo de ejecución de integración de Azure en Alemania Occidental o usando un tiempo de ejecución de Intergration Self Hosted.
Se cambiaron todas las solicitudes WEB que van hacia la API de Power BI y ahora se ejecutan correctamente. 🙂
Recibí de soporte que no hay ETA de cuándo se resolverá esto.

ver la respuesta a continuación
«

Explicación:

• Este es un problema conocido en Power BI, nos disculpamos por los inconvenientes causados ​​y nuestro equipo de productos todavía está trabajando en esta solución y aún no se ha proporcionado la ETA.
• La causa de este problema es que cierta IP de ADF Azure Integration Runtime (IR) en algunas regiones está bloqueada debido al mecanismo de protección DoS de Power BI.

Según las sugerencias de nuestro equipo de productos, intente utilizar Azure IR en otras regiones (fuera de la existente) o utilice un IR autohospedado en la actividad web como solución para este problema.
«

Hola Microsoft,

Hace un mes implementé la solución alternativa sugerida y trasladé mi ADF a otra región, desde Europa Occidental a Francia Central. Esta solución ha funcionado hasta ahora.

Desde hace unos días, estamos recibiendo el mismo problema en la región de Francia Central.

No es posible mover esto a otra región cada vez que alguien más realiza muchas solicitudes incorrectas.

¿Cuándo se solucionará este problema conocido?

Saludos,

Thomas

Hola thomas

No soy Microsoft, pero la solución para mover regiones no es la mejor, el uso de tiempos de ejecución integrados de autohost para mí funciona perfectamente.
En la respuesta de Microsoft cuando abrí un ticket en agosto, me informaron que a fines de septiembre se implementaría una solución.

Aconsejo abrir un ticket con Microsoft.

Gracias

Danny

Hola a todos,

A partir de hace 4 días, comenzamos a recibir el mismo error («La solicitud fue bloqueada por DoSP «) de nuestra canalización de actualización del conjunto de datos de Synapse PBI. Al principio, era solo una vez, tal vez cada 4 a 6 horas, y ahora se niegan 8 de cada 10 intentos. Nuestra canalización garantiza que con cada intento obtengamos un nuevo token basado en nuestro servicio. principal con el permiso adecuado y había estado funcionando bien durante más de un mes. La canalización de ejecución más frecuente es cada 30 minutos y el resto cada 6 horas. La frecuencia es un requisito de nuestros usuarios comerciales. ¿Hay alguna interfaz de usuario o Microsoft departamento donde podemos indicarle al Servicio de PBI que nuestras llamadas son de confianza? Necesitamos mantener la frecuencia actual y solucionar este problema, cualquier sugerencia sería muy apreciada.

Saludos, Fabián

Hemos abierto el ticket con MS y la respuesta fue:

Sugerencia
===========
Con respecto a su preocupación por este tema, lo verificamos con nuestro equipo de backend de power bi, indicaron que el algoritmo de Power BI está diseñado debido a consideraciones de seguridad de denegación de servicio (DoS).
La política es que si la dirección IP envía más de un cierto número de solicitudes no válidas en 1 ~ 5 minutos, la IP se bloquea durante 5 minutos. La IP solo se bloquea cuando las solicitudes no pueden pasar la autenticación.
Si alguien envía una gran cantidad de solicitudes con un token no válido, PBI debe consultar AAD y el almacén de metadatos para autenticar al usuario. Esto puede hacer que nuestro sistema caiga o afectar a otros usuarios. mientras que hay muchos clientes que comparten la misma IP mediante el uso de ADF en la misma región. Entendemos completamente que no es razonable que otro cliente lo haya bloqueado en ADF, pero desde el lado de power bi, solo recibimos la solicitud y sabemos desde qué IP está enviando y qué token trae, si es un token no válido, no es posible sabemos quién lo está enviando, lo único que sabemos es la IP de la solicitud.

Hemos confirmado con nuestro equipo de backend que actualmente no podemos cambiar esto desde el lado del poder bi sobre la IP de ADF debido a la consideración de seguridad de la denegación de servicio (DoS), hoy recibimos algunas actualizaciones del equipo de backend, están trabajando activamente en mejorando este comportamiento como solo acelerar el token no válido.

Antes de eso, podemos sugerirle que use la solución temporal a corto plazo cambiando el tiempo de ejecución de ADF a una región diferente para que podamos usar una IP diferente para desbloquear esta situación si es posible.

Hola alexander

Gracias por esta actualización.

¿También sabe cuánto tiempo tarda el algoritmo de seguridad (política) antes de que la dirección IP se borre de la lista negra?

@ Question2community: Como actualmente no hay forma de influir en el algoritmo de seguridad de PBI, nos dedicaremos a analizar más profundamente nuestras llamadas.
¿Cómo podemos validar (registros o similar) lo que están haciendo realmente nuestras llamadas de canalizaciones de Synapse a las API REST de PBI?
Cosas como reintentos, advertencias, tokens no válidos, errores, etc. Esto puede ayudarnos a identificar la causa probable.

A sugerencia de Microsoft, Al cambiar el tiempo de ejecución de ADF a una región diferente, primero tendríamos que obtener la autorización de nuestro equipo de seguridad. Además, tengo curiosidad por saber si esto se desbloqueará de forma permanente o simplemente dejará pasar las llamadas desde otra región, pero cuando regrese a la región actual, el algoritmo volverá a bloquear nuestras llamadas. ¿Conoce el comportamiento en este caso?

Saludos, Fabián

Hola Fabian, Alexander,

Implementé la solución alternativa sugerida en nuestro entorno DEV y TEST. Es un poco más de trabajo de lo que parecía originalmente, ya que no se puede «mover» una fábrica de datos existente a otra región. En su lugar, debe volver a crearlo completamente en otra región y luego aplicar todas las políticas de acceso y la configuración de seguridad necesaria.

Afortunadamente, no tuvimos que volver a crear todas nuestras fábricas de datos en otra región, «mover» la fábrica de datos de «actualización del conjunto de datos» a otra región fue suficiente. (se «trasladó» de Europa Occidental a Francia Central).

La fábrica de datos de orquestación (que reside en Europa Occidental) inició la fábrica de datos de ‘actualización del conjunto de datos’ (que reside en France Central) utilizando una llamada a la API REST.

Estoy seguro de que no todos los departamentos de TI permitirán esta solución, pero al menos puedo confirmar que está funcionando (siempre que ningún otro cliente en la región de Francia esté creando solicitudes no válidas, lo que resultará en mensajes de error DoS nuevamente).

Manténganos informados sobre la implementación del token-throttling para que podamos volver a la región original.

Saludos,

Thomas

Hola a todos,

nos encontramos con el mismo problema en todos nuestros entornos (DEV / TEST / PROD).

Todos los entornos utilizan la canalización de Data Factory para llamar a una actualización del conjunto de datos. Cada vez que se recupera un nuevo token basado en nuestro principal de servicio. Para que cada conjunto de datos se actualice, reutilizamos la misma canalización, lo que significa que para cada conjunto de datos obtenemos un token nuevo. La canalización de actualización se ejecuta dos veces en paralelo para actualizar dos conjuntos de datos diferentes.

A veces, solo uno de ambos falla, otras veces ambos fallan.

En DEV y TEST solo actualizamos una vez al día con este enfoque, en PROD 5 veces al día (que está por debajo del límite de 8 veces al día).

Esto ha estado funcionando durante meses (comenzó en marzo), y desde el 9 de agosto está fallando en 6 de cada 10 intentos.

El único mensaje que recibimos es: «La solicitud fue bloqueada por DoSP» y una dirección IP de cliente que está cambiando.

¿Alguna sugerencia sobre cómo solucionar este error?

Hoy también tenemos muchas respuestas de error de este tipo en las canalizaciones de Data Factory

Hola @MarcosSpeca,
¿Alguna operación de bucle que existía en su aplicación de inserción? Por cierto, ¿estos clientes trabajan en la misma ruta de red? ¿Algún rastro o scripts ‘web scrapy’ alojados en estos dispositivos?

Comparta información más detallada para ayudarnos a aclarar estas.

Cómo obtener una respuesta rápida a su pregunta

Saludos,

Xiaoxin Sheng

Hola

Estamos buscando bucles en nuestra aplicación, pero parece que no es el caso.

Al principio pensé que era un problema de VPN, sin embargo, el problema surgía con diferentes clientes (en diferentes redes).

Abrimos un ticket en Microsoft y el soporte está investigando el problema. Sin embargo, gracias por responder.

Hola @MarcosSpeca,

También puede echar un vistazo a los registros de auditoría de power bi si se registra alguna operación inusual.

Seguimiento de las actividades de los usuarios en Power BI – Power BI | Documentos de Microsoft
Saludos,

Xiaoxin Sheng

Sus solicitudes eran demasiado frecuentes y la herramienta de prevención / protección de denegación de servicio las ha considerado DoS y las ha bloqueado. ¿Tiene registros de red para corroborar eso?

¡Hola! Gracias por la respuesta. No estoy seguro de que las solicitudes sean demasiado frecuentes …, porque no hemos tenido ningún cambio de escenario desde que empezó el error. La cantidad de acceso por día a nuestra aplicación (que integra el informe) es la misma, los mismos usuarios y las mismas ubicaciones / IP que teníamos antes.

No tenemos ningún registro de red específico, solo este error anterior que registramos en el registro de nuestra aplicación.

Hola @MarcosSpeca

¿Recibiste algún comentario de microsoft o está resuelto?

Recibí el mismo error, incluso llamé a la API powerBI de la fábrica de datos por menos de 5 veces y al día siguiente, todavía me da ese error.

Muchas gracias

Kelvin

Hola @kelvinngai, sí, en realidad tuve que abrir un ticket de soporte.

Lo que sucedió fue que el token de inserción expiró y cuando el informe de inserción intenta obtener la información con el token caducado y se bloqueó.

Entonces, cuando nuestros usuarios intentan cambiar la página del informe con el token caducado, cada visual realiza una solicitud al servidor, y el servidor comprende estas «muchas solicitudes» con el token caducado como un riesgo y bloquea la IP del usuario.

Renovamos el token cuando está a punto de caducar en nuestra aplicación y el problema se resolvió.

Espero que esto ayude a resolver su problema.

Hola marcos

Gracias por su respuesta. Para mi caso, muestra el error en Azure Data Factory, pero no en POSTMAN

No es porque el token haya caducado. Utilizo el mismo token en POSTMAN y llamo a la actualización del conjunto de datos muchas veces, funciona bien.

Tal vez una especie de protección de red desde el lado del ADF. Intentaré usar una clave nueva en cada llamada a la API en Azure Data Factory

Gracias

Kelvin Ngai