API timeMarker.org

< Все документы:

Оглавление документа:

API

У сервиса «timeMarker.org» есть API поддерживающее SOAP и GET запросы.

Описание API доступно по адресу
http://timemarker.org/ru/Documentation.aspx?article=api

Просьба обо всех выявленных ошибках сообщать любым доступным способом:
– писать об ошибках прямо на этой странице или
– в группу Google

Предложения

1. Возможно адреса GET команд слишком длинные и сложные. Если есть идеи как их упростить прошу высказаться.

Ошибки

1. При использовании GET запроса для получения метки времени, заверяемая строка не может содержать символов переноса строки (%0d%0a). Операция заканчивается ошибкой: Bad Request – Invalid URL

Решено путем изменения УРЛ для GET-запроса (см описание).

2. При использовании SOAP символы переноса строк \r\n заменяются на \n. Это специфика SOAP.
В связи с этим, если пользователь передает сервису строку «1\r\n2», то сервис считает хеш (указывается в «метках времени» в полях Hash-SHA512 и Hash-RIPEMD160) от строки «1\n2».
Для исправления ситуации в настоящий момент все переносы строк перед посчетом хеша заменяются на \r\n.

Решено. Ввод (как для GET-запросов, так и для SOAP) осущетсвляется в base64.
Естественно это не касается ввода текста в форму на сайте.

3. Проблема при подсчете хеша от не латинских символом. (Пример – 3 сервиса выдают три разных результата от одной и той же строки).
Возможно стоит запретить получение "метки времени" на основе не латинских символов?

Комментарии [скрыть комментарии/форму]

—	SATtva (15/11/2008 16:02) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Как бы оградиться от возможных вредителей — поскольку капчи больше не будет?
Проверять ip?

Почему бы и нет? Пользователей такого функционала будет наверняка сравнительно немного. Если он кому-то понадобится, то достаточно обратиться к админу. С другой стороны, у большинства IP всё-таки динамические, а давать доступ для целой подсети может быть контрпродуктивно.

Есть и более универсальное решение — wikipedia:Hashcash. Я бы предпочёл его, хотя оно немного усложнит реализацию и клиентской части (которую проверка IP вообще не затрагивает), и серверной.

—	*Гость* (15/11/2008 20:22) <#>

>Пользователей такого функционала будет наверняка сравнительно немного. Если он кому-то понадобится, то достаточно обратиться к админу.

Я думаю что GET метод наоборот удобен для всех. Давать доступ только избранным – фантастика, и так-то не слишком большой спрос.
Я имел ввиду записывать ip на 10-20 минут и не давать делать метку чаще чем раз 10-20 минут.

—	SATtva (15/11/2008 21:00) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

А если будут активно пользоваться через Tor? Блокировка IP выйдет боком.

Вид интерфейса для меня как раз не принципиален, и GET я тоже считаю более универсальным и доступным. Hashcash легко сочетается и с GET-запросами, просто в одной из переменных передаётся токен.

—	*Гость* (16/11/2008 08:48) <#>

Я имел ввиду записывать ip на 10-20 минут и не давать делать метку чаще чем раз 10-20 минут.

Зачем? Вам чтоли жалко?

—	*Гость* (16/11/2008 09:49) <#>

>хотя оно немного усложнит реализацию и клиентской части

Очень хочется что бы все было как можно проще для клиента, в адресной строке набрал – и готово. Также можно распространять метки – просто дал ссылку на неё.

Может быть существует какой-либо способ не затрагивающий клиентскую часть?

>Зачем? Вам чтоли жалко?

Конечно нет, можно даже найти плюс — цепочка меток будет длиннее и доверия к ней будет больше. И все же давать возможность вредителю просто так забивать базу и бестолково расходовать ресурсы не хотелось бы.
Хотя кому это надо(спамить сервис)? Ладно бы нужно было какие-то знания применить. Может я зря волнуюсь?

—	*Гость* (16/11/2008 11:27) <#>

Хотя кому это надо(спамить сервис)? Ладно бы нужно было какие-то знания применить. Может я зря волнуюсь?

Решайте проблемы по мере их возникновения. Если вам действительно захотят навредить, то ограничение по ip вас не спасет, так как атакующий может воспользоваться платными прокси или ботнетом. Если вам очень сильно захотят навредить, то могут заказать DDoS атаку, от которой вас спасет только выделенный сервер, гигабитный канал и специальные железки ценой от 20 килобаксов.
От всего не убережешся, поэтому действуйте по обстоятельствам и не создавайте лишних неудобств пользователям сервиса без острой необходимости.

—	*Гость* (16/11/2008 18:25) <#>

Гость (16/11/2008 11:27), действительно. Так и сделаю.

—	SATtva (18/01/2009 16:57) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

По поводу переносов строк в запросах. Отказываться от них (как в GET) и, тем более, конвертировать (как в SOAP) — абсолютно неправильно. Для борьбы с такими явлениями следует определить, что любой ввод должен осуществляться в base64.

—	Alex_B (24/01/2009 16:08) профиль/связь <#> комментариев: 143 документов: 31 редакций: 143

Проблема с GET решена (всего-то нужно адрес запроса изменить. Еще не перенес).
Может вообще от SOAP отказаться? Кому нужен SOAP если есть GET с таким же функционалом?

Стоит ли ради сохранения SOAP делать ограничения на ввод только в base64?

—	SATtva (24/01/2009 17:33) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Может вообще от SOAP отказаться?

Ну, в питоне использование SOAP удобнее в плане простоты: импортируй SOAP-модуль и обращайся дальше к удалённым функциям, как к своим собственным. С GET мелкой возни больше. Если возможно, оставьте SOAP.

Стоит ли ради сохранения SOAP делать ограничения на ввод только в base64?

Раз с переносами в GET проблем нет, то можно требовать ввод в base64 только для SOAP, я так думаю.

—	Alex_B (25/01/2009 14:54) профиль/связь <#> комментариев: 143 документов: 31 редакций: 143

>Раз с переносами в GET проблем нет, то можно требовать ввод в base64 только для SOAP, я так думаю.

Думаю требовать разный ввод для одних и тех же методов в зависимоти от протокола не верно.
Последую совету — переделаю на ввод в base64.

Ваша оценка документа [показать результаты]