Жизнь опосредованно: использование прокси-серверов с клиентскими библиотеками Google Data API

Джефф Фишер, команда Google Data API
июнь 2007 г.

Введение: Почему прокси?

Прокси-сервер — это компьютер (или служба на компьютере), который делает запросы для ряда клиентских компьютеров от их имени, обычно к внешним ресурсам. Эта статья посвящена прокси-серверам HTTP, поскольку HTTP — это протокол, используемый для доступа к общедоступным API-интерфейсам веб-служб Google. Кроме того, прокси-серверы HTTPS или SSL также представляют интерес при отправке HTTP-запросов, содержащих конфиденциальную информацию, такую ​​как личные данные пользователя или пароли. Сегодня многие крупные компании используют прокси-серверы HTTP для управления тем, какие веб-сайты или информацию сотрудники могут просматривать в Интернете. Известно также, что публичные библиотеки и школы используют прокси для этой цели. Существует также ряд общедоступных прокси-серверов, которые можно использовать для анонимного доступа к веб-контенту.

Возможные проблемы, возникающие при использовании прокси-сервера, зависят от того, какое программное обеспечение используется и как оно настроено. Прокси считается «прозрачным», если он не изменяет запрос от клиента или ответ от сервера каким-либо образом, кроме необходимого для идентификации и аутентификации прокси. Однако большое количество прокси-серверов изменяет либо запрос, либо ответ способами, о которых должен знать разработчик. В частности, некоторые прокси-серверы будут изменять тип содержимого ответа или удалять заголовки проверки активности HTTP для отправки на внешний сервер, на котором размещается ресурс.

Так зачем разработчику использовать прокси-сервер HTTP или SSL? Как правило, для этого есть две причины: это требуется некоторой корпоративной инфраструктурой или разработчик хочет отладить приложение, использующее веб-сервис. Первая причина совершенно неизбежна, если правила сети, над которой работает разработчик, запрещают веб-соединения без прокси или SSL-соединения с внешними веб-сайтами. О последней причине часто сообщают на наших форумах поддержки разработчики, пытающиеся устранить неполадки при работе с веб-службой Google. Существуют специальные «отладочные» прокси, такие как Fiddler и Charles , которые ориентированы именно на эту ситуацию. Для получения дополнительной информации об этом использовании прокси-сервера вы можете прочитать нашу статью On the Wire: Tools for API Developers .

Для некоторых приложений добавление поддержки прокси-сервера может быть затруднено. К счастью, большинство клиентских библиотек для Google Data API можно настроить для работы с прокси-сервером HTTP после небольшой модификации кода. Эта статья предназначена для использования в качестве отправной точки для разработчика, который хотел бы использовать прокси-сервер для веб-запросов, сделанных их приложением.

Джава

Использование прокси-сервера HTTP с клиентской библиотекой Java упрощается благодаря тому, что Sun использует системные свойства для управления настройками соединения.

Например, если ваш корпоративный прокси-сервер работал на «my.proxy.domain.com» через порт 3128, вы можете добавить следующее в свой код перед созданием объекта службы для Календаря Google, Таблиц Google и т. д.

System.setProperty("http.proxyHost", "my.proxy.domain.com");
System.setProperty("http.proxyPort", "3128");

Кроме того, это можно сделать в командной строке при запуске среды сервлета:

java -Dhttp.proxyHost=my.proxy.domain.com -Dhttp.proxyPort=3128

В более поздних версиях пакета JSSE это можно распространить и на SSL-прокси. Если бы тот же прокси-сервер в предыдущем примере запускал прокси-сервер SSL на порту 3129, необходимый код был бы таким:

System.setProperty("https.proxyHost", "my.proxy.domain.com");
System.setProperty("https.proxyPort", "3129");

Это также можно сделать из командной строки так же, как с прокси-сервером HTTP.

Иногда вам может потребоваться предоставить учетные данные прокси-серверу, чтобы использовать его. Обычно они отправляются с использованием хэша base64, включенного в заголовок HTTP, следующим образом:

String encoded = new String(Base64.encodeBase64(new String("username:password").getBytes()));
String base64encodedCredentials = "Basic " + encoded;
myService.getRequestFactory().setPrivateHeader("Proxy-Authorization", base64encodedCredentials);

Обратите внимание, что приведенный выше код использует пакет кодеков Apache Commons для выполнения необходимой кодировки base64. Вам нужно будет импортировать класс org.apache.commons.codec.binary.Base64 , чтобы запустить приведенный выше код.

.СЕТЬ

Использовать прокси-сервер HTTP с клиентской библиотекой .NET не так просто, как с клиентом Java, но это можно сделать аналогичным образом при создании объекта службы для конкретного продукта.

Например, мы можем захотеть использовать прокси для взаимодействия со службой Календаря Google:

using System.Net;

CalendarService service = new CalendarService("CalendarSampleApp");
query.Uri = new Uri(calendarURI);
GDataRequestFactory requestFactory = (GDataRequestFactory) service.RequestFactory;
IWebProxy iProxy = WebRequest.DefaultWebProxy;
WebProxy myProxy = new WebProxy(iProxy.GetProxy(query.Uri));
// potentially, setup credentials on the proxy here
myProxy.Credentials = CredentialCache.DefaultCredentials;
myProxy.UseDefaultCredentials = true;
requestFactory.Proxy = myProxy;

Это должно обнаружить необходимый прокси-сервер в настройках вашего интернет-соединения — приятная функция библиотеки .NET. Однако, если вы не доверяете ему правильное обнаружение прокси-сервера, вы также можете установить его, изменив код на:

using System.Net;

CalendarService service = new CalendarService("CalendarSampleApp");
GDataRequestFactory requestFactory = (GDataRequestFactory) service.RequestFactory;
WebProxy myProxy = new WebProxy("http://my.proxy.example.com:3128/",true);
// potentially, setup credentials on the proxy here
myProxy.Credentials = CredentialCache.DefaultCredentials;
myProxy.UseDefaultCredentials = true;
requestFactory.Proxy = myProxy;

Заключение

В этой статье обсуждалось, как заставить некоторые клиентские библиотеки API данных Google работать с прокси-сервером HTTP. Разработчики, работающие за прокси-сервером в соответствии с сетевой политикой, могут по-прежнему использовать эти библиотеки. Разработчики также могут использовать прокси-сервер для отладки своего кода, заставляя прокси-сервер записывать содержимое HTTP-запросов и ответов, отправляемых в веб-службу Google и из нее. В этом руководстве не рассматриваются более сложные варианты использования прокси-сервера и других клиентских библиотек. Разработчикам, нуждающимся в дополнительной помощи, предлагается принять участие в наших общественных группах поддержки, ссылки на которые приведены ниже.

Дополнительные сведения о клиентских библиотеках, использованных в этой статье, см. на следующих страницах:

Другие источники: