возможные методы авторизации в XML-RPC?

[Axel]

возможные методы авторизации в XML-RPC?

Интересно услышать мнение общественности, кто какие методы авторизации использует при работе по XML-RPC (и в похожих техологиях вроде SOAP).

Вопрос в следующем контексте. Есть два сайта - между ними обмен данными по XML-RPC. Второй вариант: локальный клиент общающийся с сайтом по XML-RPC. В обоих случаях можно положиться на то, что первичная регистрация будет не по XML-RPC, а другими методами (регистрация на сайте или админ прописывает пароли/ключи и т.п. и каким-то отдельным способом передает их клиенту). Короче подразумеваем, что необходимые ключи/пароли у обоих сторон общения есть. Далее возникают варианты их использования.

Передавать логин и пароль с каждым запросом - простой, но очевидно неудачный путь. Надо как-то замаскировать пароль/логин. Один из вариантов - https. Но вот если https не доступен и данные приходится передавать "открытым текстом"? Ещё приходит в голову проверять IP, но тож способ не особо какой. В общем, интересно услышать кто-что пользует для решения таких задач?

 

[chameleon]

честно, сам все гоняю по https поэтому не задумывался ...
посмотри вот это: http://jimfl.tensegrity.net/eb/archives/000180.shtml

 

[S.Andrew]

Сначала тебе надо задаться вопросом какой уровень защиты тебе нужен и уже от этого плясать. Если данные действительно очень важны то старайся обеспечить https если нет то почему бы и не передавать логин пароль.

Если хочешь поизвращаться то почитай доки по сеансовым ключам. Как вариант такой способ: сервер и клиент логин пароль знают ... следовательно сервер берет текущеее время в UTS числом и оправляет его клиенту (запомнив в БД) ... клиент берет md5 от этого числа + логин и md5 от пароль + число и передает эти хеши на сервер ... сервер получив 3 переменные берет у себя ... хеши этого числа и пароля с логином из базы ... если все ок то клинту отдается следующее число ... если хеши перехватили то на следующий сеанс.

 

[Axel]

Автор оригинала: chameleon
посмотри вот это: http://jimfl.tensegrity.net/eb/archives/000180.shtml

Вот это похоже то что мне нужно. Спасибо!

S.Andrew
Сначала тебе надо задаться вопросом какой уровень защиты тебе нужен и уже от этого плясать. Если данные действительно очень важны то старайся обеспечить https если нет то почему бы и не передавать логин пароль.

Тут просто разные задачи - одна вполне конкретная: взаимодействие сайта на внешнем хостинге и БД стоящей в офисе, но тут склоняюсь к тому, что можно потребовать в обязательном порядке https, а вторая задача пока более общего плана, поскольку для разных сайтов: администрирование CMS оффлайновым клиентом - тут уже несколько мест на разных хостингах, где это будет задействовано и жёстко ограничиваться https не хотелось бы. Вот постинг в блоги в движке есть уже - там как раз логин/пароль с каждым запросом и никого это не парит, но для администрирования сайта по логике надо бы обеспечить более надёжную защиту.

S.Andrew
Как вариант такой способ:

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

 

[S.Andrew]

Если что-то найдешь качественное сообщай.

 

[Axel]

Угу. Представлю тут описание решения которое выберу, имхо на форуме эта тема пока слабо освещена, а xml-rpc штука перспективная.

 

[Orlis]

Для обмена между двумя фиксированными машинами обычно достаточно ip проверить. Ибо если кто-то сумеет подменить ip, то уж и любой ваш пароль перехватит по дороге.

 

[Qasimodo]

Автор оригинала: Orlis
Для обмена между двумя фиксированными машинами обычно достаточно ip проверить. Ибо если кто-то сумеет подменить ip, то уж и любой ваш пароль перехватит по дороге.

Иногда просто технически невозможно проверить ip.
Пример - сервер за акселератором.

 

[neko]

а у акселлератора ай-пи видимо отсутствует?
или может быть ты нам расскажешь про НАТ? ;-)

вобщем...

из всего что тут было сказано
https самый простой и надежный вариант

 

[Qasimodo]

Автор оригинала: neko
а у акселлератора ай-пи видимо отсутствует?
или может быть ты нам расскажешь про НАТ? ;-)

из всего что тут было сказано
https самый простой и надежный вариант

Повторяю медленно.
Мой скрипт выполняется на сервере с акселератором. У акселератора есть конечно же ip ,- например 10.10.10.10, или 127.0.0.1.
Но сие сакральное знание не позволяет строить acl по client ip

https далеко не самый простой способ в случае с, например, name based virtual hosting.
А также - избыточен при ненужности криптования.