¿Cómo puedo simular una visita a una url?

Question

Tengo una página donde un usuario envía un pedido y, luego de enviarlo, quiero ingresar a una url (http://externalsite.com?id=12345&sessionid=abc123) sin realmente redireccionarlos a la página externa.

¿Hay alguna manera de hacerlo?

Answer 1

Claro, utilice un HttpWebRequest desde el código del lado del servidor. He aquí un ejemplo:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(
    "http://externalsite.com?id=12345&sessionid=abc123"); 
request.Method = "GET"; 

HttpWebResponse response = (HttpWebResponse)request.GetResponse(); 
using (StreamReader reader = new StreamReader(response.GetResponseStream())) 
{ 
    string result = reader.ReadToEnd(); 
    // Process the response text if you need to... 
} 

Answer 2

Se puede utilizar la clase WebClient a los problemas de la petición HTTP en el servidor de códigos Asp.Net lado. A continuación, puede hacer lo que quiera con el html resultante.

Answer 3

Si necesita las cookies del usuario (datos de acceso y otras configuraciones de usuario) en http://externalsite.com/, puede incrustar una imagen falsa de un <iframe>o o usar una petición AJAX desde el navegador del usuario.

El uso de un <iframe>:

El uso de un "falsean" solicitud de imagen (si se puede ignorar los posibles problemas de tipo imagen):

<img src="http://externalsite.com?id=12345&sessionid=abc123" width="1" height="1" /> 

Usando jQuery's cross-browser ajax support en su forma más simple:

$.ajax({ 
    url: "http://externalsite.com?id=12345&sessionid=abc123" 
}); 

También puede aplicar formato adicional a hi del iframe o imagen, o eliminarlo usando javascript cuando ha servido para golpear al otro servidor.

Answer 4

Combinando dos de las respuestas anteriores, de voithos y Joel Purra, sugiero que considere una tercera alternativa también. A continuación está mi evaluación de cada uno:

1) La forma más segura de llegar al sitio es hacerlo desde el lado del servidor como parte de su controlador de acción para el envío real de la información del usuario. Eso se puede hacer fácilmente a través del método voithos' arriba:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(
    "http://externalsite.com?id=12345&sessionid=abc123"); 
request.Method = "GET"; 

HttpWebResponse response = (HttpWebResponse)request.GetResponse(); 
using (StreamReader reader = new StreamReader(response.GetResponseStream())) 
{ 
    string result = reader.ReadToEnd(); 
    // Process the response text if you need to... 
} 

Esto permite al servidor para golpear su servidor y asegúrese de que se llama. La desventaja de este enfoque es que hace que SU servidor tenga la sobrecarga de la solicitud HTTP secundaria. Si el otro servidor es lento, esto podría crear un problema de bloqueo que crearía una aparente lentitud en su extremo. Puede solucionar esto pasando por multiproceso/asincronismo, pero se da cuenta: presenta un montón de problemas que resolver que están fuera de su control, PERO, asegura que usted sabe si la fuente remota fue atacada o no, y cual fue la respuesta

2) Alternativamente, si su usuario realiza una publicación real y obtiene una respuesta HTML como página nueva, puede simplemente insertar la respuesta de Joel Purra en el HTML de esa página resultante, forzando al navegador del usuario a ser responsable servidor remoto.

<div style="display: none;"> 
<iframe src="http://externalsite.com?id=12345&sessionid=abc123"></iframe> 
</div> 

La desventaja de este enfoque es que si por cualquier razón sus clientes incendios fuera de la solicitud y no esperar a la siguiente página para cargar, el sitio externo devuelve un error 404, etc., no sólo se el procesamiento externo no se realiza; no sabrá que no se hizo.

3) Si tiene la capacidad de utilizar una biblioteca del lado del cliente como jQuery para hacer su procesamiento, le sugiero que haga que todo el envío del formulario se realice en línea y de manera asíncrona. El enfoque sería algo como esto:

<script type="text/javascript"> 
    $(document).bind('ready', function() { 
     $('#formSubmitButton').bind('click', function (ev) { 
      ev.preventDefault(); // These two lines stop the default processing from 
      ev.stopPropagation(); // occurring on form-submit (i.e. no full post-back) 

      // This line starts an asynchronous call to the server, posting your form 
      // data itself. 
      $.ajax({ 
       url: '/My/Post/Url', 
       type: 'POST', 
       async: false, 

       // You could use a library for this kind of form parsing. I suggest 
       // http://www.json.org/js.html - for serialization, and 
       // http://code.google.com/p/form2js/ - for form conversion. It's great. 
       data: { my: 'form', data: 'fields' }, 

       success: function (data) { 
        $.ajax({ 
         url: '/The/External/Url', 
         type: 'POST', 
         async: false, 

         data: { external: 'data', goes: 'here' }, 
         success: function (remoteData) { 
          if (remoteData) // validate response here 
           displaySuccess(); 
          else 
           displayFailure(); 
         }, 
         error: displayFailure 
        }); 
       }, 
       error: displayFailure 
      }); 
     }); 
    }); 
</script> 

En este método - que hace el cargo a su propio servidor, y en caso de éxito - disparar inmediatamente una segunda solicitud al servidor remoto. Sin embargo, debido a que espera mostrar éxito/falla al usuario hasta después de que la segunda solicitud ya se haya activado, usted sabe que al menos en la capa UI, ambas solicitudes se han realizado antes de que el cliente obtenga una cola para salir de la página.

Entonces, quizás sea más seguro desde una perspectiva de flujo de trabajo y sobrecarga, sin embargo, requiere que escriba alguna lógica de nivel de IU en JavaScript, lo que podría ser problemático, dependiendo de su proyecto.