Обновление набора данных Socrata с использованием токена приложения и частного в HTTP-базовом

Question

Я пытаюсь написать сценарий для обновления метаданных в различных наборах данных с помощью авторизованного приложения. Использование OAuth похоже на неправильный подход (это не приложение для веб-приложений для других пользователей, которое используется как сами), и передача моего собственного имени пользователя и пароля кажется ... icky.

SODA API authentication documentation довольно запутанный:

Все HTTP-основной проверкой подлинности запросы должны выполняться через защищенное соединение (HTTPS), и должны включать в себя идентификатор приложения, который получен при регистрации приложения. Тем не менее, аутентификация [sic, должно быть «приложение»?] Токены строго не требуются при аутентификации запроса. Аутентифицированные запросы, сделанные по небезопасному соединению, будут лишены.

Вот HTTP сессии пример, который использует HTTP Basic Authentication:

POST /resource/4tka-6guv.json HTTP/1.1 
Host: soda.demo.socrata.com 
Accept: */* 
Authorization: Basic [REDACTED] 
Content-Length: 253 
Content-Type: application/json 
X-App-Token: [REDACTED] 

Итак:

1. Вы можете даже использовать приложение маркер + секретный маркер для аутентификации HTTP Basic?
2. Какое из двух «[УДАЛЕНО]» - это токен приложения, и который является секретным токеном?

Мое предположение (на основе некоторых испытаний) является то, что ответы не являются:

1. Нет
2. Первый «[УДАЛЕНО]» является версия Base64 имени пользователя + пароль, то второй из них является токен приложения, который не имеет отношения к аутентификации.

Answer 1

Значки токенов и секретные маркеры на самом деле не привязаны к какой-либо проверке подлинности с предварительной подпиской. Они привязаны к вашему приложению и затем используются в OAuth, чтобы убедиться, что ваше приложение является тем, что, по его утверждению, выполняется, когда пользователь проходит через рабочий процесс OAuth. После аутентификации пользователя приложение может извлечь токен аутентификации, который используется для фактической аутентификации своих запросов.

Что вы действительно ищете - это способ получить «токен-носитель», который некоторые производители API позволяют вам генерировать. Это позволит вам в основном «pre-OAuth» и получить токен аутентификации, не пройдя полный рабочий процесс. К сожалению, мы не являемся одним из них (пока), поэтому вам нужно пройти аутентификацию с помощью простого старого HTTP Basic и вашего имени пользователя и пароля.

Если вы хотите немного-менее-icky-способ сделать это, я рекомендую зарегистрировать учетную запись «бот», которая предоставляет только необходимые разрешения для необходимых наборов данных. Тогда, по крайней мере, вы не выпекаете свои обычные учетные данные пользователя в свой конфиг. Но имейте в виду, что даже если бы у нас были жетоны-носители, вы помещали их в свой конфиг где-нибудь.

Чтобы ответить на более конкретные вопросы:

1. Нет, потому что тогда один из них должен быть знак носителем, который они не являются.
2. Заголовок Authorization является кодировкой Base64 username:password, а X-App-Token - ваш токен приложения. В этом случае последний является просто дополнительным заголовком, который идентифицирует этот запрос как полученный из вашего приложения.

Спасибо за ваши отзывы о документах. Я очищу их и постараюсь быть более простыми, и я обязательно исправлю эту опечатку.