Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Два момента:
— название статьи почти не связано с содержанием
— вместо кастомных кодов ответов лучше пользоваться стандартными HTTP: и понятны, и расшифровка не требуется.
Также непонятно, что вы сделали полезного :) Но это совсем субъективно.
— название статьи почти не связано с содержанием
— вместо кастомных кодов ответов лучше пользоваться стандартными HTTP: и понятны, и расшифровка не требуется.
Также непонятно, что вы сделали полезного :) Но это совсем субъективно.
В материале рассказал о том, как организовать контролируемую отдачу данных тем или иным пользователям (группам пользователей). Одно дело общедоступный информер аля-погода, другое дело передача конфиденциальной информации.
HTTP'ых ответов, к сожалению, не хватит для описания всех случаев. Создание таблицы кастомных кодов — нормальная практика. Платежные системы, например, так и делают.
Полезность — вещь действительно субъективная :) Возможно имело смысл посмотреть на проблему с более глубокой точки зрения — создание защищенных соединений, политика кэширования… Но я решил начать с простого, посмотреть интересно ли это людям иль нет.
HTTP'ых ответов, к сожалению, не хватит для описания всех случаев. Создание таблицы кастомных кодов — нормальная практика. Платежные системы, например, так и делают.
Полезность — вещь действительно субъективная :) Возможно имело смысл посмотреть на проблему с более глубокой точки зрения — создание защищенных соединений, политика кэширования… Но я решил начать с простого, посмотреть интересно ли это людям иль нет.
Может стоит отдавать HTTP ответы при ошибке авторизации?
Вполне, почему бы и нет. Но если вы захотите уточнить ошибку (неправильный ключ, битый токен, нехватка параметров для идентификации), то ошибку придется закастомайзить.
У iBear все правильно. В данном примере, http это транспортный протокол. А xml — протокол приложения, для маршрутизации которого, собственно и создается шлюз. Их не нужно смешивать.
Тоже соглашусь с тем, что не стоит мешать http ошибки и ошибки шлюза. Сам писал несколько шлюзов, а так же пожключался к многим другим. Как правило http ошибка говорит о том, что сообщение не удалось обработать/доставить и т.д. Ошибка же в ответе говорит именно про ошибку по протоколу.
В моей практике было несколько случаев когда в шлюзе комбинировали http ошибки и ошибки в xml ответе (были специфичные ошибки). Это все приводило к тому, что приходилось писать две обработки ответа, одна по http другая уже после успешного получения xml — в итоге немного разбросанный код.
Еще проблема в том, если в будущем возникнет необходимость использовать не только http для транспорта.
В моей практике было несколько случаев когда в шлюзе комбинировали http ошибки и ошибки в xml ответе (были специфичные ошибки). Это все приводило к тому, что приходилось писать две обработки ответа, одна по http другая уже после успешного получения xml — в итоге немного разбросанный код.
Еще проблема в том, если в будущем возникнет необходимость использовать не только http для транспорта.
Да не, вы меня не поняли :)
Я, во-первых, имел в виду, что на XML все не завязано — это может быть любой ресурс.
Во-вторых, конкретно в вашем примере с реестром кастомных кодов ответов можно и не заморачиваться: в приведенном случае хватит стандартных HTTP-response; просто раз уж решили упрощать до упора все, даже выдачу токена, не увидел смысла вводить коды. Но вам виднее, конечно.
Насчет полезности — к тому, что вместить блок с xml на 20 строк и еще на 10 расшифровку кодов не поленились, а нормальную систему токенов/авторизации оставили за бортом. Я думаю, что это был важный вопрос; если у вас есть наработки в этой области, поделитесь :)
Я, во-первых, имел в виду, что на XML все не завязано — это может быть любой ресурс.
Во-вторых, конкретно в вашем примере с реестром кастомных кодов ответов можно и не заморачиваться: в приведенном случае хватит стандартных HTTP-response; просто раз уж решили упрощать до упора все, даже выдачу токена, не увидел смысла вводить коды. Но вам виднее, конечно.
Насчет полезности — к тому, что вместить блок с xml на 20 строк и еще на 10 расшифровку кодов не поленились, а нормальную систему токенов/авторизации оставили за бортом. Я думаю, что это был важный вопрос; если у вас есть наработки в этой области, поделитесь :)
ОК, замечание принято :)
Могу попозже написать продолжение, в котором сделаю акцент именно на безопасность транзакций (шифрование данных, создание подписей, WS-Security, SAML, интеграцию LDAP или Active Directory, XKMS, SSL конечно же… HTTP-авторизацию тоже можно не забывать), рассказать о более сложной схеме:
Клиент -> SSL/TLS -> Контент-свитчер -> Шлюзы -> Сервера/сервисы
Могу попозже написать продолжение, в котором сделаю акцент именно на безопасность транзакций (шифрование данных, создание подписей, WS-Security, SAML, интеграцию LDAP или Active Directory, XKMS, SSL конечно же… HTTP-авторизацию тоже можно не забывать), рассказать о более сложной схеме:
Клиент -> SSL/TLS -> Контент-свитчер -> Шлюзы -> Сервера/сервисы
Насчет привязки токена авторизации к доступным категориям, это конечно хорошо, но получается что клиенту каждый раз придется отдавать не только токен но и список всех категорий, даже если необходимо получить записи из всех категорий. Не проще ли дать юзеру логин с паролем и по нему авторизовать и отдавать временный токен.
*получить запись из одной категории*
Конечно же привязывать к категориям не обязательно, я привел это в качестве примера, как второй возможный параметр. Им, например, может быть ID какого-то мероприятия, в рамках которого действует партнер. Либо такого параметра может не быть вовсе.
Логин/пароль — тоже вполне себе хорошая схема. Можно хоть проверять правильность связки, хоть HTTP Basic access authentication вешать на доступ к шлюу. Но мне привязка к IP сервера больше импонирует, т.к. пароль можно «потерять».
Логин/пароль — тоже вполне себе хорошая схема. Можно хоть проверять правильность связки, хоть HTTP Basic access authentication вешать на доступ к шлюу. Но мне привязка к IP сервера больше импонирует, т.к. пароль можно «потерять».
Генерация мне не нравится, поэтому внесу своих 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/
<?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/
Зря вы HTTP_X_FORWARDED_FOR используете.
В этот хидер можно прописать все что угодно, таким образом подделав IP.
Тоесть человек может зайти с любого IP прописав требуемый IP в этот хидер.
В этот хидер можно прописать все что угодно, таким образом подделав IP.
Тоесть человек может зайти с любого IP прописав требуемый IP в этот хидер.
Точно. HTTP_X_FORWARDED_FOR — для рюшечек всяких, не для контроля безопасности. В смысле IP единственная информация, которой можно доверять — REMOTE_ADDR. Если его нет — значит нет информации об IP, достойной доверия.
Кстати, очень ценное замечание. Действительно HTTP_X_FORWARDED_FOR и HTTP_CLIENT_IP можно подменить.
немного похоже на схему аутентификации вконтакте.
Второй момент, сложение категорий, у Вас получилось «1259», а если категорий больше 10?
Второй момент, сложение категорий, у Вас получилось «1259», а если категорий больше 10?
ну это, конечно, мелочи
Сложение категорий совсем не обязательно, это был просто пример второго юзер-зависимого атрибута. Его можно исключить полностью, либо заменить на что-то другое.
да я понял, что пример, вот и подписал ниже, что это мелочи :)
Вы в одном параметре token смешали access и authentication. Практики этот подвох чувствуют нутром. В такой схеме, появляются ненужные аномалии. Например, клиент проплативший доступ еще к одной категории документов, автоматически теряет возможность подключаться к ресурсу, пока не обновит ключ на своем сервере.
С открытием вас Америки, капитан!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
XML-шлюз своими руками