кто-то уже откодил и оттестировал. а теперь кодит баги.

Надо кодить без багов ;)

Ну это врядле, в свете последних угонов аккаунтов...

По теме инвайтов. Раз уж на то пошло, то выдавать нужно API ключи как у гугла например (для SOAP выдавали ключи). С помощью ключей можно и вести мониторинг нагрузки создаваемой определенными юзерами. Тех кто будет тянуть еже секундно можно банить, и тогда они уже больше не побеспокоят. Но ограничивать их выдачю помоему это неправильно.

З.Ы. Не знаю как AlienZzzz считал, но я насчитал минимум 5 человек...

Интересная статья - по перебору паролей - почитайте. Пароль в 9 символов удобен, да и долговечен к брут-форсу. А про md5 я вообще молчу.


если использовать MD5 в api - то это самый шик.

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

Согласен на все 100. Ибо это основа Web-Service'ов. Если он есть, то он доступен для всех и всегда, иначе он платный.

Да я не про пароли. Я про то что в онлайн сервисах для SAPE свой пароль никто никогда не введет. Если на то пошло, то Шифровать в МД5 (+ какое-то секретное число или слово) нужно на стороне клиента. В ДжаваСкрипте с МД5 будет сложновато

Отдавать пароль сервису только в MD5, а он должен отправлять запросы только с MD5 параметром. Всё просто!

1. пароль и так идет в МД5 (там есть параметр)
2. проше https сделать, чем мутить с отдачей только с пареметром мд5.

Salt не нужен, достаточно иметь длинный пароль - больше 15-20 символов :).

мы говорим о совершенно разных вещах.

публичный сервис А. Для регистрации требуют ввести пароль от Сапы. Вы ведь не введёте, да? Так там нужен выбор - ввод md5-пароля - тоесть клиент сам генерирует md5 и вводит его на сайте.
Смысл защиты не от перехвата, а от владельцев сервиса.

Ну вот если сделают вход в аккаунт на сайте тоже по md5 (на js), то соль пригодилась бы.

Зачем? Ну есть у меня игрушка - скрипт, брутфорса md5, но пароль больше 5 символов раскрывать не доводилось :).
Кстати, я бы в стороннем -онлайн-сервисе не доверил бы свой пароль даже для JS. По крайней мере если бы не разбирался в JS, ведь пароли можно аккуратно положить в куки и при следующем обращении к серваку вынуть в чистом виде ;).
Так что кодирование пароля в md5 - это дело клиента без участия сервиса. Так надежнее.

Вы не поняли суть. Сессия на сапе привязывается к IP адресу (если я не путаю), желательно конечно чтобы она привязывалась и к интерфейсу (api, www).

А в идеале было бы в настройках аккаунта указать какие функции должны быть доступны по API, да и альтернативный пароль бы тоже не помешал.

Сессия привязывается к устанавливаемому в куках ID сессии.

ID сессии хранится в куках
а сама сессия должна быть недействительна с других IP.

Сейчас работатет. И не факт что это хорошая мера защиты... провайдеры бывают очень разные...

сколько наговорили однако:)

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

насчёт трафика
невелика разница, что парсить html, что xml, а точнее, не существенна
для скорости, идеальный вариант, всё равно будет txt с разделителями:)

не знаю, вхожу ли я в ту "пятерку", как говорили выше, кто пользуется хмл, но думаю, что намного больше:)

кроме http://www.sape.ru/api_xmlrpc.php ещё есть что-то, что не видно:)?

CSV подходит для плоских таблиц, но никак не подходит для вложенных структур. Тут лучше всего будет использовать YAML - гибкость почти как у XML, простота почти как у CSV, и не так сильно раздувается размер передаваемых данных (за счет меньшего кол-ва разметки).

Вы тут велики то не придумывайте. сжатый XML решает.

нууу ... раз такое дело, тогда сразу в *.dbf например, и маркеров не нуна :))

Кончаем баловаться :). Хватит и просто сжатия существующего XML.
САПА, дайош сжатый XML! :D

Сжатие - вопрос весьма спорный, так как на сервер ложится дополнительная нагрузка, и весьма большая (если запросов будет много). Я не думаю что объемы данных не настолько большие что их нужно обязательно сжимать. Могу сказать за себя, мне сжатие не нужно.

тогда скажу и за себя:)
мне хочется в 3 файла получать оптимизаторские данные, а не запрашивать десяток проджект айди для всех урлов, а потом линксайди каждого урла

логично было бы использовать "id=-1", для получения всех данных

Это решается вынесением процессов сжатия данных на отдельный сервер. И не нужно забывать, что при сжатии пропускная способность канала увеличивается не менее чем в 2 раза (при пересчете на не сжатые данные).

Объемы весьма немаленькие. От нескольких мегабайт до нескольких десятков мегабайт.

Речь идет не о том, что нужно вам или еще либо кому, а что нужно всем, с точки зрения САПЫ, вам забирать только свои данные, а сапе отдавать данные почти всех ;).

Да, было бы гораздо удобнее, еслибы можно было запрашивать все данные по всем проектам сразу, да еще и в сжатом виде.
Один-два раза в день скачал все данные и этого вполне достаточно.

Ну я же написал, что высказываю ИМХО :) если будет компрессия то я только рад дополнительно буду :)

Уважаемые, а вот с помощью этого xml-rpc-интерфейса можно получить для каждого конкретного проекта такие параметры как: кол-во ссылок на страницах 1/2/3 уровней, установленные цены на страницы 1/2/3 уровней и (если есть) списки урлов, для которых отдельно была указана цена? Ну и множитель на контекстные ссылки.
Я пока этого через интерфейс извлечь не могу, чтоб придать скрипту сбора статистики законченный вид :(

Да, кстати ещё вопросец: кто как подключается через xml-rpc? Я использую ZendFramework, но может есть более компактный набор функций?

Качайте всю информацию по проекту, его страницам и размещённым ссылкам. Делайте анализ и будут заветные цифры.

именно

Похоже произошли изменения в выдаче данных. Месяц назад я получал другой набор :) Вопрос снят.

Хочу serialized PHP. Уверен, что для многих это будет наилучшим решением.
Кстати, не мог бы кто-нибудь скинуть пример использования интерфейса на PHP, не могу разобраться с документацией.

В принципе сериализованные данные будет лучшим вариантом (особенно в сжатом виде). Но кроме PHP есть еще и другие языки, которые могут не понять...

Просто надо опцию как в яху апис сделать - формат вывода.

Да, можно при логине сразу указывать в качестве параметра, чтоб он в сессии сохранялся.

и это Вы называете прогрессией в программировании? Это деградация!

Помоему здесь никто не говорил ни о какой прогрессии :). Речь идет об удобстве.

И в чем же удобство?

Юродствуете? Или у вас это серьезно?

Выглядит сложнее чем обработка XML? Или может быть вы думаете, что обработка XML происходит быстрее?

Не юродствую и не серьезно... вообще странные вопросы у вас, мне интересно ваше мнение, вообще-то...

Я знаю, что обработка и получение XML через RPC происходит сложнее и дольше, однако всеравно не вижу причины, почему ее необходимо заменить на сериализацию :) Как написал big.bon, и я с ним полностью согласен, сериализация это скорее деградация в программировании (имеется ввиду не сераиализация в принципе, а сериализация как результат работы Веб-Сервиса), это всеравно что сейчас перейти на goto: вместо циклов. :)

У каждого свои задачи, вылизывать код и оттачивать свое мастерство в программировании, или максимально быстро получить нужные данные и использовать выигранное время на увеличение доходов. Я выбираю второе. Может кто-то первое, поэтому и предлагается возможность сделать выбор формата выдачи.

Так я только за :) просто через сериализацию это выглядит немного странно, не считаете? К тому же сериализация есть на PHP на уровне ядра, однако для того же Perl'а она не реализована, и прийдется прикручивать к скрипту еще один велосипед чтобы расшифровать данные. Про Ruby, Java и # направления я уже молчу.