Клуб Фоток

Клуб Фоток

У Яндекс.Фоток появилось API

У Яндекс.Фоток появилось собственное API.

С помощью API разработчики приложений и сервисов могут создать программу для загрузки фотографий на Яндекс.Фотки, создания и редактирования альбомов и многого другого. (Кстати, клиент для IPhone и Мобильные Яндекс.Фотки сделаны с применением именно этого API).

Мы приглашаем разработчиков фотоклиентов и программ для работы с изображениями использовать API Яндекс.Фоток. 

Страница API Яндекс.Фоток находится здесь: http://api.yandex.ru/fotki, там же находится вся документация. Комментарии, вопросы и предложения можно писать либо в ответ на эту запись, либо в клубе сервиса Яндекс.Фоток

Удачи!

29 комментариев
Авторизуйтесь, чтобы оставить комментарий
derigel
28 января 2016, 01:34
Ура!
derigel
28 января 2016, 01:34
Только главная проблема с передачей своего логина и пароля от яндекса третьей стороне так и не решена. Как недоверяли продвинутые пользователи третьим сервисам свой пароль, так и не будут доверять. К срвисам самого яндекса, пользующихся этим же api доверия конечно-же больше.
Удалённый пользователь
28 января 2016, 01:34
А где передача логина/пароля третьей стороне?
Ntropy
28 января 2016, 01:34
Вот тут http://team23.ru/picasa.html
derigel
28 января 2016, 01:34
Мне, в плагин передается логин и пароль, в чистом виде. А я уж его шифрую и на Яндекс передаю. Плагин необязательно на локальной машине, это может быть веб-служба какая-то. Да даже и локальный - доступ в интернет открыт. ;)
derigel
28 января 2016, 01:34
OAuth, OAuth, OAuth! ))
ijon
28 января 2016, 01:34
Если пользователь установил программу локально -- он доверился её автору. Без вариантов. На пользовательской машине и без яндексового аккаунта есть много чего интересного. С веб-сервисами, понятно, сложнее. В общем, эзоповым языком, но Соглашение API Фоток не позволяет создавать веб-службы, которые бы брали яндексовые логины-пароли своих конечных пользователей. OAuth хотим сами.
derigel
28 января 2016, 01:34
А насчет запрещения создавать веб-службы - это который пункт? Я только увидел один акаунт на одного пользователя.
ijon
28 января 2016, 01:34
Я расказал о духе, буква подтянется. Кроме того всегда остаётся пункт 6 главного Пользовательского соглашения (http://rules.yandex.ru/).
Удалённый пользователь
28 января 2016, 01:34
Можно токен просить. :-)
derigel
28 января 2016, 01:34
Ну вот это почти OAuth и есть :) Вы сделайте сервис токены раздующий, я буду пользователей туда посылать ;)
bigsales
28 января 2016, 01:34
нужен доступ к поиску по фоткам через API
Denis T.
28 января 2016, 01:34
http://fotki.yandex.ru/rss/search.xml?text=эротика&skin=rss2 ?
bigsales
28 января 2016, 01:34
Может быть, надо пощупать, то или не то
Демид Л
28 января 2016, 01:34
А почему собственно "В настоящий момент для шифрования credentials требуется использовать специальную библиотеку RSA-шифрации, исходные тексты которой для С/С++ доступны по адресу url"
Denis T.
28 января 2016, 01:34
а какой именно вопрос?
Демид Л
28 января 2016, 01:34
Так используется общечеловеческий RSA и base64 или какие-то специально модифицированые? Если обычные то зачем приложены исходники и такое предостережение, если нет то тогда совсем странно:)
ijon
28 января 2016, 01:34
Объективно "общечеловеческого" RSA не существует. Есть разные реализации, совместимые сами с собой, и, иногда, друг с другом (если их авторы этого специально захотели). В сервисе выдачи токенов в настоящий момент используется своя реализация, не совместимая более ни с чем. Нас это не радует, поэтому о поддержке стандартных (распространённых) схем и вариантов шифрации мы думаем.
ypuser
28 января 2016, 01:34

похоже что, библиотека RSA шифрования не работает на Windows,
token не выдаётся с одной и той же ошибкой 400 Bad Request Malformed credentials data

ijon
28 января 2016, 01:34
"Malformed credentials data" указывает на другое. Два момента:
  1. шифровать, кодировать в base64 и отсылать в качестве параметра credentials нужно всю строку ""
  2. если POST формируется с content-type application/x-www-form-urlencoded, то параметр credentials нужно ещё дополнительно urlencode'ить.
ypuser
28 января 2016, 01:34

1. шифруем login, кодируем в base64

2. шифруем password, кодируем в base64

3. составляем credentials строку с зашифрованными и кодированными

выше login/password

3. затем _всю_ строку credentials кодируем в base64

4. затем urlencoding для всей строки при условии что Content-Type

is application/x-www-form-urlencoded

Так ?

 

ijon
28 января 2016, 01:34
Не так. Шифрация применяется только один раз:

1. составляем строку "", где вместо {логин} и {пароль} идут настоящие логин-пароль
2. шифруем всю эту строку, результат кодируем в base64

Затем, если применяется form-urlencode POST -- да, urlencode, и результат посылается как параметр credentials.

(Можно использовать multipart/formdata POST, тогда urlencode не требуется).
ypuser
28 января 2016, 01:34

спасибо, заработало.

меня смутило вот что (из документации API):

"Логин и пароль нужно предварительно зашифровать при помощи полученного ключа RSA, а затем закодировать в base64."

помоему идёт в разрез с этим:

"2. шифруем всю эту строку, результат кодируем в base64"

 

ijon
28 января 2016, 01:34
Да, в этом месте в документации текст невнятный -- "логин и пароль" не воспринимается сокращением от "строки с логином и паролем" как должно было бы. Правильно написано в примере использования.
Исправим, спасибо.
2bj
28 января 2016, 01:34
Больше часа потратил чтобы полчить токен.

еще нужно заменить что енкриптер нужно запускать с параметром "--no-b64encode"
ijon
28 января 2016, 01:34
Можно -- если потом кодировать результат encrypt в base64 самому -- но странно. Если уж используется программа encrypt (которая, однако только пример использования библиотеки, а не штатная утилита), то зачем отключать встроенную кодировку в base64?

encrypt без "--no-b64encode" уже выдаёт ровно то, что нужно отсылать в качестве credentials (за минусом необязательного urlencode).
Иван Ш.
28 января 2016, 01:34
1.2.4. Запрещается организовывать любыми способами использование одного и того же аккаунта и идентификатора на Яндекс.Фотках или на Яндексе более, чем одним конечным пользователем. А если я сделаю на своем сайте хитрое пользовательское соглашение, что в момент загрузки пользователи даруют фотографии мне, и уже я гружу фотографии на сайт Яндекса? Судя по всему, проект «Фотосайт за 5 минут» сделать с текущим пользовательским соглашением не получится. А счастье было так возможно. Скажем прямо, фотосайты делать – это тяжкая работа, много файлов, как только пользователей становится много, сразу проблемы с отдачей большого числа файлов, не говоря про то, что изменение размеров фотографий съедает ресурсы процессора. Поэтому запуститься фотохостинг на мощностях Яндекса выглядит привлекательным, можно было бы даже платить за подобный сервис, как за трафик так и за дисковую квоту.
Denis T.
28 января 2016, 01:34
если вы так сделаете - то мы заблокируем ваш аккаунт, в соответствии с п. 1.2.4 этого ПС и пункта 9 ПС Яндекса. Делать конструктов фотохостингов - не наш бизнес, если честно.
im4LF
28 января 2016, 01:34
Хочу залить все свои фото с локальной машины на Я.Фотки.

Альбомы создаются без проблем, но загрузить фотки никак не удаётся - в ответ получаю:

HTTP/1.1 417 Expectation Failed
Connection: close
Content-Length: 0
Date: Sun, 24 May 2009 12:27:19 GMT
Server: lighttpd/1.4.18

Попробовал оба варианта, описанных в документации.
Это ваш временный баг или мои кривые руки?