Документацию не читай, в рассылку пиши. Вообще-то там оба метода просят логин, пароль, идентификатор и токен приложения. Просто в первом случае идентификатор и токен передаётся в заголовке Authorization, а во втором - явными параметрами запроса.
2017-08-29 12:26 GMT+03:00 Orlovsky Alexander via Moscow-pm <[email protected]>: > По ссылке два метода, один с логином/паролем, а второй с логином, паролем, > идентификатором и токеном. > Проблема, в том что в этом тупо нет смысла. Я его не улавливаю. Зачем > форсить логин/пароль если есть oauth реквизиты и, наоборот, зачем эти oauth > реквизиты если всё равно форсятся логин и пароль? > > 28.08.2017, 23:35, "Alexander Gnatyna" <[email protected]>: > > Это очень старое апи и оно еще по почте могло работать, когда токенов ещё не > было. Наследие одним словом. но зато реализовать работу с ним очень просто. > > 28 авг. 2017 г. 20:41 пользователь "Orlovsky Alexander via Moscow-pm" > <[email protected]> написал: > > Всем привет! > Хочу поныть тут, потому что есть подозрение что рассылку могут читать > инсайдеры из руцентра. > > Такой вопрос, зачем в API просить логи и пароль, когда типа предоставляешь > oauth доступ по токену? > > Вот тут https://www.nic.ru/api/oauth/get_token.html в разделе «Запрос в > случае явной передачи идентификатора и пароля приложения» есть как > client_id/client_secret, что ожидаемо, так и username/password и вот это > совершенно необъяснимо. Зачем? > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > -- //wbr, Dmitry L. -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
