2015-08-03 3 views
2

Я ценю ваше время. Я неожиданно попал в кирпичную стену, отправив запрос GET в API профиля Google, в котором сервер всегда отвечает неавторизованной ошибкой 401. Я кодирую с использованием C# и пытаюсь реализовать ручной поток для проверки подлинности пользователя. В моем приложении Windows используется элемент управления браузером для начального входного процесса, а затем выполняется уход за ним в фоновом режиме.Trouble Generating GET Запросы к профилю Google

Все отлично работает: я могу получить код авторизации с сервера с помощью HttpWebRequest/HttpWebResponse, обработать ответ, отправить другой запрос для токена доступа и обработать этот ответ. Моя проблема возникает на следующем этапе: отправка запроса GET на URL профиля API для получения информации о профиле пользователя. Я не буду утомлять вас весь код, я просто покажу вам важные вещи:

Это может быть частью проблемы так ...

Начальный URL Authentication строка:

https://accounts.google.com/o/oauth2/auth?scope=profile%20email&redirect_uri={my redirect uri}&response_type=code&client_id={my client id}&approval_prompt=force&access_type=offline 

Возможно, я использую неправильный способ с указанием областей в URL-адресе, и поэтому полученный токен доступа не совпадает с URL-адресом API, который я использую?

Далее ...

запрос GET выглядит следующим образом:

string RequestString = "https://www.googleapis.com/plus/v1/people/me?access_token=" + AccessToken; 

WebRequest GGLRequest = WebRequest.Create(RequestString); 
GGLRequest.Method = "GET"; 
// I've already tried alternating use of 
// these next 4 lines without improvement: 
GGLRequest.ContentLength = 0; 
GGLRequest.ContentType="application/json"; 
GGLRequest.Headers.Add("Authorization", "Bearer"); 
GGLRequest.UseDefaultCredentials = true; 

WebResponse GGLResponse = GGLRequest.GetResponse(); 

Кодовые взрывает на последнюю строку с 401 Несанкционированной ошибкой.

Теперь, возможно, я запрашиваю неправильный URL? Если да, то какой правильный?

1) Google+ API активирован в моем проекте на сайте консоли.

2) Идентификатор клиента/секретный и перенаправляемый URI, полученные от Google, настроены для «Установленных приложений», поскольку это приложение Windows Form.

3) Предварительно запрос GET с использованием того же формата выполняется без проблем. Получается ответ от URL tokeninfo с информацией о Токе доступа, отправленном Google, чтобы я мог проверить привязанный к нему идентификатор пользователя. Кажется странным, что он работает отлично, а другой - нет.

Опять же, я ценю ваше время! Ура!

+0

Выполняют ли два запроса сразу после друг друга? Или есть задержка? Допуск access_token действителен только за час до того, как вы получите новый с токеном обновления. Пробовали ли вы регистрировать точные URL/params для двух запросов, чтобы убедиться, что они используют точно такой же access_token? – abraham

+0

Абрахам, спасибо за ваше время, взглянув на мою проблему! На самом деле они происходят один за другим; задержки недостаточно для того, чтобы токен доступа истекал. – Arnie

ответ

1

Я разрешил ситуацию, с которой я столкнулся!

Когда вы отправляете GET-запросы в Google (и я представляю себе любую другую корпоративную услугу, такую ​​как их), вам необходимо выполнить ее с помощью защищенной строки (SSL/TLS и т. Д.). Это не приведет к множеству ошибок в зависимости от вашей конкретной схемы. В моем случае тот же код давал мне различные типы ошибок на линии .GetResponse, один тип на работе и один тип дома (видимо, поскольку я за работой Active Directory на работе). Я упоминаю эту маленькую деталь, потому что это был тот фактор, из-за которого моя лампочка включалась и начинала смотреть в определенном направлении ;-)

Теперь, в ходе предыдущего исследования, я наткнулся на статью (прошу прощения за то, что не включая потому что я позорно потерял его), объясняя, что WebRequest автоматически использует SSL, когда «https» - это протокол, указанный в URL-адресе.К сожалению, этого недостаточно.

Вам необходимо принудительно установить SSL/TLS в коде.

Наконец я наткнулся на This Article прямо здесь, на переполнение стека, что дало мне свет, в котором я нуждался. Я просто должен был добавить следующие строки кода до выдачи WebRequest (ы):

ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; // Tls for Facebook 
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; }; 

Так что это ... и она работала отлично! Надеюсь, это поможет любому, у кого есть такая же проблема, в будущем.

Отличный день!

Смежные вопросы