Я искал в Google и StackOverflow, чтобы найти ответ на свой вопрос, но я не могу его найти.
Я хотел бы сохранить access_token в моей базе данных для автономного доступа, и я бы хотел указать правильную длину моего столбца.
Я даже не могу найти, просто ли это число или комбинация между числом и строками.
Я работаю в Facebook, и я могу дать окончательный ответ об этом.
Не помещайте максимальный размер в хранилище для токена доступа. Мы ожидаем, что со временем они будут расти и сокращаться, когда мы добавим и удалим данные и изменим их кодировку.
Мы дали указание в одном месте о том, что оно составляет 255 символов. Я обновил сообщение в блоге с этой информацией и обновил наши новые документы токена доступа, чтобы добавить примечание о размерах:
https://developers.facebook.com/docs/facebook-login/access-tokens/
Извините за путаницу.
С недавним переходом Facebook на зашифрованные токены доступа длина токена доступа может составлять до 255 символов. Если вы храните токен доступа в своей базе данных, столбец должен иметь возможность размещения как минимум varchar (255). Вот выдержка из блога Facebook Developer от 4 октября 2011 года:
"При включенной миграции токена шифрованного доступа формат токена доступа изменился. Новый формат токена доступа полностью непрозрачен, и вы не должны зависеть от формата в коде. varchar (255 ) будет достаточно для хранения новых токенов."
Полное сообщение в блоге: https://developers.facebook.com/blog/post/572
Этот ответ уже не правильный, и я не могу найти исправленное значение в документах FB. Мы получили токены доступа, длина которых превышает 255 символов. Мы переходим от VARCHAR к SMALLTEXT вместо этого, чтобы попытаться найти будущее.
Из раздела 1.4 The OAuth 2.0 Authorization Protocol (draft-ietf-oauth-v2-22)
Доступ к токенам может иметь разные форматы, структуры и методы использования (например, криптографических свойств) на основе требования к безопасности сервера ресурсов. Атрибуты доступа к токену и методы, используемые для доступа к защищенным ресурсам, выходят за рамки этой спецификации и определяются спецификациями компаньона.
Я искал "спецификации компаньона", но не нашел ничего подходящего, и в разделе 11.2.2 он указывает
o Имя параметра: access_token
o Местоположение использования параметров: ответ авторизации, ответ токена
o Контроллер изменения: IETF
o Документ спецификации: [[этот документ]]
Как видно, параметр access_token определен в этой спецификации. Которое я предполагаю, что параметр есть, но фактический токен доступа не полностью скомпонован.
Обновление: Последняя версия этой записи спецификации (draft-ietf-oauth-v2-31) содержит приложение, которое лучше определяет, что ожидать от параметра access_token
А .12. Синтаксис "access_token"
The "access_token" element is defined in Section 4.2.2 and Section 5.1: access-token = 1*VSCHAR
Итак, в сущности, это означает, что access_token должен иметь длину не менее 1 символа, но нет предела тому, как долго определено в этой спецификации.
Обратите внимание, что они определяют VSCHAR =% x20-7E
токен доступа Facebook может быть длиннее 255 символов. У меня было много ошибок, таких как ActiveRecord::StatementInvalid: PG::StringDataRightTruncation: ERROR: value too long for type character varying(255), где значением был токен доступа к facebook. Не используйте столбец типа string, потому что его длина ограничена. Вы можете использовать столбец типа text для хранения токенов.
Недавно наше приложение увидело их более 100 символов. Я все еще ищу документацию, поэтому могу определить размер "безопасного" поля для них.
Я обновлю ответ, потратив время.
Из документации OAuth2,
Размер строки токена доступа остается undefined по этой спецификации. Клиент должен избегать предположений о размерах значений. Сервер авторизации должен документировать размер любого значения, которое он выдает.
(раздел 4.2.2 этот документ)
Примечание. Facebook использует OAuth2, как указано на этой странице.
Итак, теперь ни одна информация не доступна на портале разработчиков Facebook о длине токена OAuth. Yahoo, похоже, использует токен длиной в 400 бит, поэтому лучше предположить, что столбец TEXT в MySQL безопаснее, чем varchar.