visual-studio proxy wcf-security fiddler ntlm

Usar Fiddler para olfatear las solicitudes de Visual Studio 2013(firewall proxy)



visual-studio wcf-security (3)

Alternativamente, puede usar la forma ligera como;

if (Debugger.IsAttached) {request.Proxy = new WebProxy (" http://localhost:8888/ ", verdadero); }

Tengo problemas con Visual Studio 2013 y nuestro proxy corporativo (el inicio de sesión no funciona, las actualizaciones no funcionan, la galería visual studio no funciona, nuget y git fallan). Todos estos están haciendo solicitudes http o https. (por ejemplo, http://visualstudiogallery.msdn.microsoft.com/ ). En VS2013 acabo de girar barras de progreso o mensajes sobre la falta de conexión de red.

No hay problema con el navegador, (Chrome, IE, Firefox) ya que todos entienden los proxies (407 rechazos y luego responden con credenciales).

Entonces quiero descubrir por qué VS2013 no funciona. Pero no puedo ver ningún tráfico cuando le digo a fiddler2 que mire el proceso DEVENV.EXE (o todos los procesos).

Por cierto, he intentado algunos cambios en el archivo web.config (devenv.exe.config) para asegurarme de que va al proxy (vi esto en el generador de la pila) pero no funciona para mí. Ver las adiciones a la siguiente sección:

<system.net> <defaultProxy useDefaultCredentials="true" enabled="true"> <proxy proxyaddress="http://gw6.OURSITE.com:3128" /> </defaultProxy> <settings> <ipv6 enabled="true"/> <servicePointManager expect100Continue="false" /> </settings> </system.net>

Actualizar

Eric, tomé tu sugerencia y simplemente la C:/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/IDE/devenv.exe.config archivo C:/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/IDE/devenv.exe.config .

Lo que puse fue:

<system.net> <defaultProxy useDefaultCredentials="true" enabled="true"> <proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" usesystemdefault="false" /> </defaultProxy> </system.net>

Lo que encontré fue que VS2013 no está enviando una cadena de agente de usuario. Sí sabe sobre # 407 naks y responde con credenciales, pero la puerta de enlace todavía quiere un agente de usuario:

HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Type: text/html; charset=utf-8 Proxy-Connection: close Connection: close Content-Length: 1341 <html> <head> <title>Access Policy Denied: No User-Agent Specified</title> <meta name="description" content="Web Access Policy"> </head> <body>



Si desea ver el tráfico con Fiddler, probablemente desee ir por la ruta de cambiar el archivo machine.config para que todas las aplicaciones .NET envíen tráfico a través de Fiddler. Esto ayuda a garantizar que capture datos de procesos que se ejecutan en servicios, etc.

Abra machine.config en la carpeta C:/Windows/Microsoft.NET/Framework/v4.0.30319/Config . Tenga en cuenta que si está depurando un servicio de 64 bits (como ASP.NET), querrá buscar en la carpeta Framework64 lugar de hacerlo en la carpeta Framework. Del mismo modo, si está utilizando una versión de .NET anterior a la 4.0, deberá ajustar la parte de la versión de la ruta.

Agregue el siguiente bloque XML como un igual al elemento system.net existente, reemplazando cualquier elemento defaultProxy existente si está presente:

<!-- The following section is to force use of Fiddler for all applications, including those running in service accounts --> <system.net> <defaultProxy enabled = "true" useDefaultCredentials = "true"> <proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" usesystemdefault="false" /> </defaultProxy> </system.net>

Ref http://fiddler2.com/blog/blog/2013/01/08/capturing-traffic-from-.net-services-with-fiddler

Nota: Puede usar Fiddler para insertar un encabezado User-Agent en las solicitudes salientes si lo desea. Además, en la última versión de Fiddler, puede Archivo> Importar> Captura de paquetes para recopilar tráfico HTTP de archivos .cap capturados con Microsoft NetMon o Microsoft Message Analyzer.