Как стать автором
Обновить

Комментарии 26

Два момента:
— название статьи почти не связано с содержанием
— вместо кастомных кодов ответов лучше пользоваться стандартными HTTP: и понятны, и расшифровка не требуется.

Также непонятно, что вы сделали полезного :) Но это совсем субъективно.
В материале рассказал о том, как организовать контролируемую отдачу данных тем или иным пользователям (группам пользователей). Одно дело общедоступный информер аля-погода, другое дело передача конфиденциальной информации.

HTTP'ых ответов, к сожалению, не хватит для описания всех случаев. Создание таблицы кастомных кодов — нормальная практика. Платежные системы, например, так и делают.

Полезность — вещь действительно субъективная :) Возможно имело смысл посмотреть на проблему с более глубокой точки зрения — создание защищенных соединений, политика кэширования… Но я решил начать с простого, посмотреть интересно ли это людям иль нет.
Может стоит отдавать HTTP ответы при ошибке авторизации?
Вполне, почему бы и нет. Но если вы захотите уточнить ошибку (неправильный ключ, битый токен, нехватка параметров для идентификации), то ошибку придется закастомайзить.
У iBear все правильно. В данном примере, http это транспортный протокол. А xml — протокол приложения, для маршрутизации которого, собственно и создается шлюз. Их не нужно смешивать.
Тоже соглашусь с тем, что не стоит мешать http ошибки и ошибки шлюза. Сам писал несколько шлюзов, а так же пожключался к многим другим. Как правило http ошибка говорит о том, что сообщение не удалось обработать/доставить и т.д. Ошибка же в ответе говорит именно про ошибку по протоколу.
В моей практике было несколько случаев когда в шлюзе комбинировали http ошибки и ошибки в xml ответе (были специфичные ошибки). Это все приводило к тому, что приходилось писать две обработки ответа, одна по http другая уже после успешного получения xml — в итоге немного разбросанный код.
Еще проблема в том, если в будущем возникнет необходимость использовать не только http для транспорта.
Да не, вы меня не поняли :)

Я, во-первых, имел в виду, что на XML все не завязано — это может быть любой ресурс.

Во-вторых, конкретно в вашем примере с реестром кастомных кодов ответов можно и не заморачиваться: в приведенном случае хватит стандартных HTTP-response; просто раз уж решили упрощать до упора все, даже выдачу токена, не увидел смысла вводить коды. Но вам виднее, конечно.

Насчет полезности — к тому, что вместить блок с xml на 20 строк и еще на 10 расшифровку кодов не поленились, а нормальную систему токенов/авторизации оставили за бортом. Я думаю, что это был важный вопрос; если у вас есть наработки в этой области, поделитесь :)
ОК, замечание принято :)

Могу попозже написать продолжение, в котором сделаю акцент именно на безопасность транзакций (шифрование данных, создание подписей, WS-Security, SAML, интеграцию LDAP или Active Directory, XKMS, SSL конечно же… HTTP-авторизацию тоже можно не забывать), рассказать о более сложной схеме:
Клиент -> SSL/TLS -> Контент-свитчер -> Шлюзы -> Сервера/сервисы
Насчет привязки токена авторизации к доступным категориям, это конечно хорошо, но получается что клиенту каждый раз придется отдавать не только токен но и список всех категорий, даже если необходимо получить записи из всех категорий. Не проще ли дать юзеру логин с паролем и по нему авторизовать и отдавать временный токен.
*получить запись из одной категории*
Конечно же привязывать к категориям не обязательно, я привел это в качестве примера, как второй возможный параметр. Им, например, может быть ID какого-то мероприятия, в рамках которого действует партнер. Либо такого параметра может не быть вовсе.

Логин/пароль — тоже вполне себе хорошая схема. Можно хоть проверять правильность связки, хоть HTTP Basic access authentication вешать на доступ к шлюу. Но мне привязка к IP сервера больше импонирует, т.к. пароль можно «потерять».
Не проще переписать на DOMXML функционале?
Генерация мне не нравится, поэтому внесу своих 5 копеек :)

<?php
$s = simplexml_load_string('<?xml version="1.0" encoding="utf-8"?><response></response>');
$s->{'error-code'} = 0;
$content = $s->addChild('content');

//эмуляция данных
$i = array(
array('element_id'=>1,
'category_id'=>5,
'title'=>'Заголовок 1',
'text'=>'Текст элемента номер 1, про всякую фигню',
'time'=>'1248770309'
),
array('element_id'=>2,
'category_id'=>9,
'title'=>'Заголовок 2',
'text'=>'Текст элемента номер 2, про всякую фигню',
'time'=>'1248770319'
)
);

//генерация
foreach ($i as $v) {
$item = $content->addChild('item');
$item->element_id = $v['element_id'];
$item->category_id = $v['category_id'];
$item->title = $v['title'];
$item->text = $v['text'];
$item->time = $v['time'];
}

echo $s->asXML();

dumpz.org/10997/
Реализацию я оставляю на совесть исполнителя, о чем писал выше ;)

Еще можно использовать XMLWriter или DOMDocument — как душе поэта угодно!
Зря вы HTTP_X_FORWARDED_FOR используете.
В этот хидер можно прописать все что угодно, таким образом подделав IP.

Тоесть человек может зайти с любого IP прописав требуемый IP в этот хидер.
Точно. HTTP_X_FORWARDED_FOR — для рюшечек всяких, не для контроля безопасности. В смысле IP единственная информация, которой можно доверять — REMOTE_ADDR. Если его нет — значит нет информации об IP, достойной доверия.
Кстати, очень ценное замечание. Действительно HTTP_X_FORWARDED_FOR и HTTP_CLIENT_IP можно подменить.
вообще HTTP_* можно подменить, если я не ошибаюсь. Так что на них надежды нет.
немного похоже на схему аутентификации вконтакте.
Второй момент, сложение категорий, у Вас получилось «1259», а если категорий больше 10?
ну это, конечно, мелочи
Сложение категорий совсем не обязательно, это был просто пример второго юзер-зависимого атрибута. Его можно исключить полностью, либо заменить на что-то другое.
да я понял, что пример, вот и подписал ниже, что это мелочи :)
Вы в одном параметре token смешали access и authentication. Практики этот подвох чувствуют нутром. В такой схеме, появляются ненужные аномалии. Например, клиент проплативший доступ еще к одной категории документов, автоматически теряет возможность подключаться к ресурсу, пока не обновит ключ на своем сервере.
С открытием вас Америки, капитан!
А не проще ли использовать вместо этого SOAP-веб-сервис?
Реализация сервера и клиентов здорово упрощается за счет использования готовых компонентов для работы с SOAP. В частности, в PHP есть расширение soap.so и Pear Soap.
А не проще ли вместо мыла использовать XML-RPC? Странно, что про него еще никто не сказал.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории