Jak mogę zasymulować wizytę w adresie URL?

Question

Mam stronę, na której użytkownik przesyła zamówienie, a po jej przesłaniu chcę kliknąć adres URL (http://externalsite.com?id=12345&sessionid=abc123) bez konieczności przekierowania ich na stronę zewnętrzną.

Czy istnieje sposób, aby to zrobić?

Answer 1

Oczywiście, użyj HttpWebRequest z kodu po stronie serwera. Oto przykład:

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

Można użyć klasy WebClient kwestii żądania HTTP na serwerze kodu strona ASP.NET. Możesz wtedy zrobić cokolwiek chcesz z wynikowym html.

Answer 3

Jeśli potrzebujesz cookie użytkownika (dane logowania i innych ustawień użytkownika) na http://externalsite.com/ można osadzić <iframe>lub się podrobić zdjęcie lub użyć żądania AJAX z przeglądarki użytkownika.

Używanie <iframe>:

Używanie "podrobić" żądania obrazu (jeśli można zignorować wszelkie potencjalne problemy Typ obrazu):

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

Korzystanie jQuery's cross-browser ajax support w najprostszej postaci:

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

Możesz również zastosować dodatkowe formatowanie do hi de iframe lub obraz, lub usuń go za pomocą javascript, gdy ma służyć do uderzania drugiego serwera.

Answer 4

Łącząc dwie z powyższych odpowiedzi, z voithos i Joela Purry, proponuję rozważyć trzecią alternatywę. Poniżej znajduje się moja ocena każdego z nich:

1) Bardziej pewnym sposobem trafienia na stronę jest wykonanie strony serwerowej jako części programu obsługi akcji dla rzeczywistego przekazywania informacji użytkownika. Że można łatwo zrobić dzięki metodzie powyżej voithos':

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... 
} 

Pozwala serwer uderzyć ich serwera i upewnić się, że zostanie wywołany. Wadą tego podejścia jest to, że sprawia, że ​​serwer YOUR ma narzut dodatkowego żądania HTTP. Jeśli drugi serwer działa wolno, może to spowodować problem blokujący, który spowoduje wyraźne spowolnienie na końcu. Możesz obejść to, przechodząc w tryb wielowątkowy/asynchroniczny - ale otrzymujesz obraz: wprowadza szereg problemów do rozwiązania, które są poza twoją kontrolą - ALE - zapewnia to, że wiesz, czy zdalne źródło zostało trafione, czy też nie. jaka była odpowiedź.

2) Alternatywnie, jeśli użytkownik tworzy rzeczywisty wpis i otrzymuje odpowiedź HTML jako nową stronę, można po prostu wprowadzić odpowiedź Joela Purry do HTML strony wynikowej, zmuszając przeglądarkę użytkownika do ponoszenia odpowiedzialności za zdalny serwer.

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

Wadą tego podejścia jest to, że jeśli z jakiegoś powodu swoich klientów pożary wyłączyć wniosek i nie czekać na następnej stronie, aby załadować, strona zewnętrzna zwraca błąd 404, itd., Nie tylko przetwarzanie zewnętrzne nie zostanie wykonane - nie będziesz wiedział, że nie zostało to zrobione.

3) Jeśli masz możliwość korzystania z biblioteki po stronie klienta, takiej jak jQuery do przetwarzania, sugerowałbym, aby wszystkie formularze były przesyłane w trybie in-line i asynchronicznie. Podejście byłoby coś takiego:

<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> 

W ten sposób - zrobić post na własnym serwerze, a na sukces - natychmiast wystrzelić drugą żądanie do serwera zdalnego. Ponieważ jednak oczekuje się, że użytkownik wyświetli komunikat o powodzeniu/niepowodzeniu, dopóki drugie żądanie nie zostanie już uruchomione - wiesz, że przynajmniej w warstwie interfejsu użytkownika obie żądania zostały wykonane, zanim klient otrzyma kolejkę do opuszczenia strony.

A więc - być może bezpieczniej z perspektywy przepływu pracy i kosztów ogólnych - wymaga to jednak napisania pewnej logiki poziomu interfejsu użytkownika w JavaScript, co może być problematyczne, w zależności od projektu.