мой redirect_uri приводит к предупреждению о невозможности подключения

Мой вопрос является продолжением как программно создать окно аутентификации/входа. В одном из ответов на этот вопрос было предложено посмотреть пример кода в https://meta.stackexchange.com/a/293498/148310.

Я реализовал этот код, и теперь я могу получить окно входа/аутентификации. Теперь проблема заключается в том, что сразу после ввода моих учетных данных я перенаправляюсь на указанный мной URL-адрес redirect_uri (localhost, см. изображение), где браузер жалуется на «Проблему с загрузкой страницы», «Невозможно подключиться», ошибка / предупреждение (щелкните, чтобы увидеть изображение), ситуация, которая, по моему мнению, прерывает выполнение моего кода . Обратите внимание, что желаемый номер токена доступа, по-видимому, прикреплен к концу URL-адреса, как и должно быть, несмотря на проблемы с загрузкой страницы в браузере. Проблема в том, что мой код завершается из-за проблемы с загрузкой браузера, прежде чем он сможет прочитать токен с перенаправленной страницы.

Приведенный ниже фрагмент моего кода (также включенный в пример кода, приведенный в ссылке выше) просматривает URL-адрес окна, чтобы определить, перенаправил ли браузер (на что указывает наличие «oauth/login_success» в URL-адресе). Код рассматривает перенаправленный браузер как признак успешного входа/аутентификации пользователя; токен доступа в конце URL-адреса готов к программному извлечению и применению. (В моем случае я хочу, чтобы код использовал токен в вызове API для загрузки файла bibtex из моей учетной записи исследовательской группы Mendeley). В противном случае инициируется выполнение процесса входа/аутентификации.

function getInfo()
{
if (location.pathname == "/oauth/login_success") {
processOauthPopup ();
}
else {
authorizeAndThenRunMain ();
}
} 

В моем коде в конце функции authorizeAndThenRunMain у меня есть обратный вызов getInfo(), ожидая, что затем код выберет функцию processOathPopup. Напротив, кажется, что код останавливает выполнение, когда браузер перенаправляется на локальный хост. Если я снова нажму кнопку на моей странице ShareLatex, чтобы инициировать еще один вызов getInfo, я просто снова увижу экран входа/аутентификации. Код никогда не занимается извлечением токена доступа (в конце перенаправленного URL-адреса, показанного на изображении) и выполнением желаемых задач в рамках функции processOauthPopup().

Чтобы перейти к сути, мой вопрос заключается в следующем: как я могу указать своему коду игнорировать тот факт, что окно перенаправления имеет ошибку загрузки, и просто продолжить извлечение токена из URL в этом окне и продолжить выполнение функции processOathPopup?

Чтобы уточнить немного больше, я предполагаю, что в моем коде есть две потенциальные проблемы, которые могут иметь отношение к проблеме кода, никогда не выбирающего опцию processOathPopup:

  1. Мой скрипт GreaseMonkey запускается на странице www.sharelatex.com/projects/xxxxx, где xxxxx относится к учетной записи пользователя и документу, редактируемому в этой учетной записи (вспомните Google Диск, где каждый документ имеет уникальный идентификационный номер). Мой код ведет меня на сайт api.mendeley.com/oauth/, где я аутентифицируюсь и вхожу в систему, а затем меня перенаправляют на ссылку localhost:5000/oauth/login_success (см. изображение). Основная проблема заключается в том, что мой URL-адрес перенаправления указывает на localhost, а не обратно на sharelatex.com?

    • If so, would it matter that an "www.sharelatex.com/oauth/login_success" does not point to a real website?
    • Если действительно «sharelatex» должен быть частью URL-адреса перенаправления, должен ли он быть идентичным URL-адресу страницы sharelatex, с которой я начал? Или это может быть усеченный адрес с отредактированной информацией, относящейся к документу (например, описанный выше материал xxxxx, который ссылается на конкретный документ в sharelatex). Необходимость проходить через систему регистрации пользовательских скриптов Mendeley для изменения URL-адреса каждый раз, когда я хочу использовать этот код для другого документа sharelatex, была бы нехорошей. Даже в этом случае «/oauth/login_success», прикрепленный к законному URL-адресу, приведет к перенаправлению URL-адреса, который указывает на несуществующий веб-сайт, что, как я думаю, является проблемой с использованием перенаправления localhost.
  2. Для того, чтобы location.pathname когда-либо совпадал с «/oauth/login_success», не должно ли окно перенаправления загружаться/заменять мое окно sharelatex, откуда я первоначально запускал выполнение кода (мой код GreaseMonkey делает кнопка на моем веб-сайте ShareLatex, которую я использую, чтобы инициировать выполнение вышеуказанной функции getInfo).

    • Or is location.pathname smart enough to point to whatever tab in the browser was most recently opened (e.g, the api.mendeley.com followed by the redirected localhost URLS), rather than always pointing to the sharelatex.com window from which the javascript/userscript was launched?
    • Если действительно location.pathname указывает на самую последнюю вкладку, а не на исходное окно sharelatex.com, то как мне заставить код указывать на исходное окно ShareLatex, чтобы он мог отслеживать будущие события нажатия кнопки там ?

Я так запутался ... Любая помощь будет принята с благодарностью!


person PMM    schedule 07.10.2017    source источник
comment
Я не собираюсь тратить на это время (другие могут помочь), но ваше перенаправление должно быть на сайт, который: (А) существует, (Б) подпадает под действие ваших директив @match и (В) вы не доверяете злоупотреблять вашими учетными данными (хотя серверы обычно их не видят). Вероятно, вы можете использовать https://stackexchange.com/oauth/login_success без проблем. Он хорошо себя ведет и заслуживает доверия.   -  person Brock Adams    schedule 07.10.2017
comment
Спасибо @BrockAdams. Жаль, что не было исчерпывающего, подробного пошагового руководства пользователя: Как запустить пользовательский скрипт на одном веб-сайте, который может инициировать вход/авторизацию на другом веб-сайте, с возвращением управления на первый веб-сайт для продолжения мониторинга для инициированных пользователем События. После прочтения сотен вопросов и ответов stackoverflow за ~ 2 месяца, когда я работал над рабочим кодом, я могу с уверенностью сказать, что многие другие так же сбиты с толку, как и я, в отношении Oauth2. Представлено слишком много абстрактной теории и недостаточно прикладной информации, такой как эти 3 эмпирических правила для URL-адреса перенаправления, которые вы предоставили.   -  person PMM    schedule 07.10.2017