#c# #wcf #web-services
#c# #wcf #веб-службы
Вопрос:
Существует веб-служба, которая может использоваться только через http, и клиент, который может использовать только веб-службы https. Поэтому мне нужен какой-то посредник, который пересылает запросы, полученные по протоколу https, и возвращает ответы по протоколу http.
Предположим, что посредник полностью тупой, за исключением того факта, что он знает, где находится конечная точка веб-службы (т. Е. Он не знает, какова сигнатура службы, он просто знает, что он может взаимодействовать с ним через веб-запрос http, и он прослушивает некоторый uri https, перенаправляя на что угодноон получает), каков самый простой способ добиться этого?
Я играл с этим весь день и не уверен, как добиться «тупого» бита, то есть не зная подписи для передачи обратно дословного ответа.
Комментарии:
1. Вы уверены в ограничении HTTP / HTTPS? HTTPS по-прежнему является HTTP, только по защищенному соединению. Возможно, вы сможете решить свою проблему, просто используя перенаправление портов с 443 на 80 (при условии, что клиент принимает простые HTTP-ответы)
2. Мне сказали, что перенаправление портов не является вариантом. Не уверен, почему это так, но это часть спецификации; может быть, потому, что клиент находится за пределами интрасети компании, поэтому не может вернуться по http.
3. Что вы пробовали до сих пор? Разве это не просто выполнение HTTP POST с исходной полезной нагрузкой SOAP от клиента (возможно, после удаления учетных данных клиента) на конечную конечную точку и возврат ответа обратно?
4. @muratgu: Проблема, вероятно, в том, что конечная точка WCF уже получила полезную нагрузку от клиента, преобразовав ее в какой-то объект. WCF, вероятно, будет бороться с вами в подобном случае.
5. @mellamokb: Да, это моя проблема. Как вернуть «полезную нагрузку» в чистом виде.
Ответ №1:
Тупой посредник — это, по сути, прокси. Ваш лучший выбор может быть просто использовать стандартный asp.net страницы (вместо того, чтобы подключаться к сервисным функциям, таким как ASMX или WCF, которые просто будут бороться с вами), чтобы вы могли получить запрос точно как есть и обработать его простым способом, используя стандартный запрос / ответ. Вы можете использовать HttpWebRequest class для пересылки запроса на другую конечную точку.
- Клиентские запросы https://myserver.com/forwarder.aspx?forwardUrl=http://3rdparty.com/api/login
- myserver.com (ваш прокси-сервер) считывает строку
forwardUrlзапроса и любой включенный запрос POST или GET. - myserver.com просьбы к http://3rdparty.com/api/login и передает данные GET или POST, отправленные от клиента.
- myserver.com принимает ответ и отправляет обратно в качестве ответа на другую конечную точку (по сути, просто
Response.Writeсодержимое в ответ)
Вам нужно будет написать forwarder.aspx для обработки запросов. Код для forwarder.aspx будет примерно таким (непроверенный):
protected void Page_Load(object sender, EventArgs e)
{
var forwardUrl = Request.QueryString["forwardUrl"];
var post = new StreamReader(Request.InputStream).ReadToEnd();
var req = (HttpWebRequest) HttpWebRequest.Create(forwardUrl);
new StreamWriter(req.GetRequestStream()).Write(post);
var resp = (HttpWebResponse)req.GetResponse();
var result = new StreamReader(resp.GetResponseStream).ReadToEnd();
Response.Write(result); // send result back to caller
}
Комментарии:
1. Это было направление, в котором я двигался. Спасибо за это, я попробую это сейчас и отчитаюсь.
2. Возможно, вы захотите узнать, как использовать Fiddler, чтобы помочь отслеживать трафик и диагностировать проблемы, если что-то не работает: fiddler2.com/fiddler2 . Кроме того, я не подумал о том, что если API использует файлы cookie для отслеживания сеанса, это также необходимо будет обработать.
3. Приветствия, это сделало работу. Выполнение этого через прокси-сайт — определенно правильный подход! Мне также удалось расширить код, чтобы он также обрабатывал SOAP. Надеюсь, мне не нужно будет настраивать файлы cookie, но я узнаю об этом в понедельник, когда кто-нибудь действительно даст мне спецификацию. И во время моих путешествий я обнаружил это membrane-soa.org/soap-router.htm Который я надеюсь продать ИТ-специалистам вместо моего варианта с домашним сайтом, который, я просто знаю, закончится плачевно, и я получу по шее.
4. Просто хотел еще раз сказать спасибо за это. После развертывания оказалось, что это был запрос SOAP, а не REST ( очевидно , мне просто дали URL-адрес и сказали, чтобы он работал). Однако этот подход работает для обоих, и возможность доступа к нему в режиме RESTful была очень удобна с точки зрения отладки.