@dside Хм. Ну, Го, кстати, умеет по-бырику раскручивать веб-сервер.
Но ладно. А что мне мешает просто по этому урлу с особым значением сходить курлом и взять код?
Top-level
@dside Хм. Ну, Го, кстати, умеет по-бырику раскручивать веб-сервер. Но ладно. А что мне мешает просто по этому урлу с особым значением сходить курлом и взять код? 9 comments
@dside Я хочу избежать их *хранения*. Ну, а так - это единственные реквизиты, доступные пользователю, пусть введет разок. @drq тогда проще спрашивать прямо логин с паролем и делать запрос токенов с grant_type: password, что и делает Authenticate. Выглядит он работоспособным. И никакая возня с /oauth/authorize и authorization code в процессе не появляется вообще. @drq да нет, не придётся. Ты ж по итогам процедуры всё равно получишь access token и тебе точно так же его сохранять. @drq так с ним не надо логиниться, он готов к применению. Создать клиент, где токен присвоен в Config.AccessToken, и поехал. |
@drq если ты /oauth/authorize в залогиненном браузере открываешь, то этот же браузер по редиректу и пойдёт.
Поэтому адрес назначения в редиректе должен вести в приложение, чтобы приложение могло достать значение кода самостоятельно.
А иначе в этой затее нет смысла.
Если редирект будет на мёртвую ссылку, то браузер успешно пойдёт и по ней. И код можно будет скопировать из адресной строки, если хочется, но со специальной страницы Мастодона это делать всё же удобнее.
А если ты хочешь и чтоб на /oauth/authorize приложение сходило само, это ему нужны будут логин+пароль или сессия, чего ты вроде как хочешь избежать.
@mo
@drq если ты /oauth/authorize в залогиненном браузере открываешь, то этот же браузер по редиректу и пойдёт.
Поэтому адрес назначения в редиректе должен вести в приложение, чтобы приложение могло достать значение кода самостоятельно.
А иначе в этой затее нет смысла.
Если редирект будет на мёртвую ссылку, то браузер успешно пойдёт и по ней. И код можно будет скопировать из адресной строки, если хочется, но со специальной страницы Мастодона это делать всё же удобнее.