Успешный GitHub OAuth не перенаправляет через заголовок Location
я использую PHPoAuthLib вместе с GitHub, чтобы обеспечить простую систему входа OAuth для моего веб-приложения PHP. Я скопировал пример но столкнулись с проблемой: перенаправление из GitHub не обрабатывается браузером.
Мое приложение успешно перенаправляет на страницу авторизации GitHub, которая выглядит следующим образом:
GitHub генерирует страницу, которая затем среди большого количества заголовков включает в себя следующее:
Location: http://awooga.local/auth?code=5fb910f67xxxxx91003
Тем не менее, это не обрабатывается браузером. Сначала я подумал, что это проблема в фреймворке Slim, который я тоже использую. Я поэтому вырезал это, и проблема осталась. Я тогда попробовал wget на URL GitHub и найдите, что GitHub сгенерировал страницу с ошибкой, которая включает в себя эту очень общую ошибку:
<div id="ajax-error-message" class="flash flash-error">
<span class="octicon octicon-alert"></span>
<a href="#" class="octicon octicon-x flash-close js-ajax-error-dismiss" aria-label="Dismiss error"></a>
Something went wrong with that request. Please try again.
</div>
Это объясняет, почему это не работает в браузере — вы не можете сделать Location перенаправить, если HTML был отправлен. Однако странным является то, что если я возьму URL-адрес перенаправления и вставлю его вручную в свой браузер, он получит аутентификация действительно сработала. Таким образом, насколько я могу судить, у GitHub нет причин жаловаться на проблему.
(В случае, если это не ясно, http://awooga.local домен отлично работает на моей машине — он настроен в локальном DNS, чтобы указать 127.0.0.1).
Этот вопрос звучит похоже, но решение, которое сработало в этом случае, не сработало в моем (и я не понимаю, как это могло бы изменить ситуацию: автор предлагает, чтобы URL входа в GH был прямой ссылкой в приложении, а не редирект).
Сценарий публикации 1: Мне было интересно, мог ли GH счесть проблематичным локальный домен. Чтобы проверить эту теорию, я переписал реальную область с 127.0.0.1 запись в моем /etc/hosts, обменялись учетными данными, чтобы они соответствовали зарегистрированному приложению на GH, и попытались снова. Я получаю точно такое же поведение: перенаправление получено, но не выполнено. Я предполагаю, что происходит то, что ранее было обнаружено через wget — неспецифическая ошибка в ответе HTML препятствует работе перенаправления.
Сценарий публикации 2: я исключил библиотеку OAuth. Я использовал вариант ответа ниже, чтобы использовать необработанные операции cURL в PHP, который делает то же самое, что и выше — Location Заголовок заблокирован, возможно, потому что GH сообщает о неспецифической проблеме в ответе HTML. Так как я использую прямой URL для GH /login/oauth/authorize Конечная точка Я не вижу, что может пойти не так. Затем я извлекаю местоположение из ответа, вставляю его в свой браузер, и он работает нормально — он получает токен доступа из GitHub, который затем можно использовать для запуска пользовательского вызова. Вся моя информация пользователя получена успешно.
Я добавляю несколько заголовков запросов / ответов от Firefox, на случай, если это поможет пролить свет на проблему:
https://github.com/login/oauth/authorize?client_id=xxx&redirect_uri = HTTP: //awooga.local/auth2.php
Запрос:
Host:"github.com"User-Agent:"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0"Accept:"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"Accept-Language:"en-gb,en;q=0.5"Accept-Encoding:"gzip, deflate"Referer:"http://awooga.local/auth"Cookie:"logged_in=yes; <stripped for security>"DNT:"1"Connection:"keep-alive"Отклик:
Cache-Control:"no-cache, private"Content-Type:"text/html; charset=utf-8"Date:"Sat, 27 Dec 2014 19:31:59 GMT"Location:"http://awooga.local/auth2.php?code=zzz"Server:"GitHub.com"Set-Cookie:"user_session=aaa; path=/; expires=Sat, 10-Jan-2015 19:31:59 GMT; secure; HttpOnly
_gh_sess=??; path=/; secure; HttpOnly"Status:"302 Found"Strict-Transport-Security:"max-age=31536000; includeSubdomains; preload"Transfer-Encoding:"chunked"Vary:"X-PJAX, Accept-Encoding"X-Content-Type-Options:"nosniff"X-Frame-Options:"deny"X-GitHub-Request-Id:"(stripped)"X-GitHub-Session-Id:"(stripped)"X-GitHub-User:"halfer"X-Rack-Cache:"miss"X-Request-Id:"(stripped)"X-Runtime:"0.016812"X-Served-By:"(stripped)"X-XSS-Protection:"1; mode=block"content-security-policy:"default-src *; script-src assets-cdn.github.com collector-cdn.github.com; object-src assets-cdn.github.com; style-src 'self' 'unsafe-inline' 'unsafe-eval' assets-cdn.github.com; img-src 'self' data: assets-cdn.github.com identicons.github.com www.google-analytics.com collector.githubapp.com *.githubusercontent.com *.gravatar.com *.wp.com; media-src 'none'; frame-src 'self' render.githubusercontent.com gist.github.com www.youtube.com player.vimeo.com checkout.paypal.com; font-src assets-cdn.github.com; connect-src 'self' ghconduit.com:25035 live.github.com uploads.github.com www.google-analytics.com s3.amazonaws.com"x-ua-compatible:"IE=Edge,chrome=1"Сценарий публикации 3: я попробовал то же самое в другом браузере в моей системе, Midori, и он работает нормально. Так что это либо проблема браузера (или, возможно, Midori с удовольствием перенаправит, несмотря на то, что получил HTML-контент в ответе о перенаправлении).
Решение
http://awooga.local это не real домен.
посмотрите небольшой пример здесь: http://githubv3.herokuapp.com/
======== Update =========
Извините за мисс, ведущую туда; (
Вот пример кода, который я написал:
index.html
<html>
<head>
</head>
<body>
hi,there
<br>
<!-- replace with your own client_id and redirect uri -->
<a href="https://github.com/login/oauth/authorize?client_id=YourClientId&redirect_uri=http://www.sites.com/github/callback.php">github login</a>
</body>
</html>
callback.php
<?php
if(isset($_GET['code'])){
$code = $_GET['code'];
// post to get access_token
$ch = curl_init();
curl_setopt($ch, CURLOPT_POST, true);
// your own client_id and client_secret
$url = "https://github.com/login/oauth/access_token?client_id=YourClientId&client_secret=YourClientSecret&code=$code";
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
'Accept: application/json'
));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$result = curl_exec($ch);
if($result === false){
echo 'curl error'.curl_error($ch);
}else{
$response = json_decode($result, true);
$accessToken = $response['access_token'];
if(!empty($accessToken)){
$ch = curl_init();
$url = "https://api.github.com/user?access_token=$accessToken";
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
'Accept: application/vnd.github.v3+json'
));
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.6 Safari/537.11");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$result = curl_exec($ch);
if($result === false){
echo 'curl error'.curl_error($ch);
}else{
echo 'auth user info:<br>';
var_dump($result);
}
}else{
echo 'access_token empty';
}
}
curl_close($ch);
}else{
echo 'no code';
}
Другие решения
Я исправил это, хотя я не полностью уверен, что пошло не так. Я попробовал Midori, а затем отдельную установку Firefox, и оба работали нормально. Таким образом, я отключил некоторые плагины в моей обычной установке Firefox, и он начал перенаправлять правильно.
Странно, но я снова включил нарушающий плагин (-ы) и теперь не могу заставить его снова выйти из строя. Возможно, процесс отключения и повторного включения сбрасывает их каким-то образом? Кажется, было Foxy Proxy это было ответственно, но так как я снова включил его без проблем, я теперь не так уверен.