id: Гость   вход   регистрация
текущее время 11:08 28/03/2024
Вступить во владение (создано 15/11/2008 15:07), редакция от 08/07/2009 12:55 (автор: Гость) Печать
Категории: инфобезопасность, разное
создать
просмотр
редакции
ссылки

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

Думаю требовать разный ввод для одних и тех же методов в зависимоти от протокола не верно.
Последую совету — переделаю на ввод в base64.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3